Enterprise Website Accessibility Acceptance Tests

This article provides a practical acceptance testing framework for enterprise websites, covering test environment setup, keyboard and focus testing, semantic structure and ARIA validation, and color contrast checks. It includes a defect logging template to standardize issue reporting.

Test Environment and Preparation

Before you begin acceptance testing, establish a controlled environment that mirrors your production setup. This ensures results are reproducible and defects can be reliably retested.

Start by defining the exact browser and assistive technology combinations you will support. At a minimum, include the latest versions of Chrome, Firefox, Safari, and Edge.

For screen readers, test with NVDA on Windows and VoiceOver on macOS, as these are the most commonly used in enterprise environments.

Also include automated scanning tools such as axe and Lighthouse to catch common issues early, but remember that automated tools cannot detect all accessibility problems—manual testing is essential.

Next, define the scope of pages to test. Do not test every page in your site; instead, select a representative sample that covers all unique templates and components. Include your homepage, at least one form page (e. g.

, contact or login), a page with dynamic content (e. g. , a search results page or a modal dialog), and a page with complex widgets like dropdown menus or tabs. Document the exact URLs and the date of testing.

For each test session, record the tester name, browser version, operating system, and any assistive technology used. This information is critical for reproducing defects later.

Finally, establish a baseline by running an automated scan on each selected page. This gives you a starting point and helps identify obvious issues before manual testing. Record the results and use them to prioritize your manual efforts.

Remember that automated tools have limitations—they can check for missing alt text or low contrast, but they cannot evaluate whether a focus order is logical or whether an ARIA attribute is used correctly.

Your acceptance criteria should combine both automated and manual checks.

Keyboard and Focus

Keyboard accessibility is a fundamental requirement for users who cannot use a mouse. Your acceptance tests must verify that all functionality is operable via keyboard alone. Start by testing the Tab order.

Press Tab repeatedly and observe whether the focus moves in a logical sequence that matches the visual layout. For example, on a typical page, focus should move from the header navigation to the main content, then to the footer.

If the order jumps around, that is a defect.

Focus visibility is equally important. Users must be able to see where they are on the page. Check that a visible focus indicator (such as a focus ring) appears around links, buttons, and form fields when they receive keyboard focus.

If the indicator is missing or too subtle, it fails the acceptance criteria. Also test skip navigation links. These links, usually placed at the top of the page, allow keyboard users to bypass repetitive navigation and jump directly to main content.

Verify that the skip link becomes visible on focus and that it moves focus to the intended target.

For interactive widgets like modals, dropdowns, and accordions, test that they can be opened and closed using the keyboard.

For example, a modal should open when the trigger button is activated with Enter or Space, and it should close when the Escape key is pressed. Focus should move into the modal when it opens and return to the trigger button when it closes.

If focus is trapped inside the modal or lost entirely, that is a critical defect. Also test that all interactive elements within the widget are reachable via Tab and that arrow keys work for selecting options in dropdowns or radio groups.

Semantic Structure and ARIA

Semantic HTML provides meaning to assistive technologies, allowing screen reader users to navigate and understand the page structure. Your acceptance tests should verify that the page uses correct HTML tags for its content.

Check the heading hierarchy: there should be one h1 for the main page title, followed by h2s for major sections, and so on. Headings should not skip levels (e. g. , jumping from h2 to h4).

Use a tool like the W3C HTML Validator or browser extensions to inspect the heading outline.

Lists should be marked up with ul, ol, and li tags, and tables should use th for header cells and caption for titles. Buttons should be actual button elements, not divs or spans with click handlers.

If you find a div that acts as a button, that is a defect because screen readers will not announce it as a button. Similarly, links should be anchor tags with an href attribute.

ARIA (Accessible Rich Internet Applications) attributes are used to enhance accessibility when native HTML is insufficient. Check that ARIA attributes are used correctly.

For example, aria-label can provide an accessible name for an icon button, aria-expanded indicates whether a dropdown is open, and aria-live announces dynamic content updates. Verify that these attributes are present and have appropriate values.

For instance, a button that opens a menu should have aria-expanded="false" when closed and aria-expanded="true" when open. Also ensure that iframes, such as embedded videos or maps, have a title attribute that describes their content.

If an iframe lacks a title, screen reader users will not know what it contains.

Color Contrast and Visual Design

Color contrast is essential for users with low vision. Your acceptance tests must ensure that text and UI components meet the contrast ratios defined in the Web Content Accessibility Guidelines (WCAG).

Use tools like the WebAIM Contrast Checker to test contrast. For normal-sized text (under 18pt or 14pt bold), the contrast ratio should be at least 4. 5:1. For large text (18pt or 14pt bold and above), the ratio should be at least 3:1.

UI components, such as form field borders and focus indicators, also need a contrast ratio of at least 3:1 against adjacent colors.

Test all text on the page, including body copy, headings, placeholder text, and error messages. Pay special attention to text overlaid on images or gradients, as contrast can vary. If a color combination fails, it is a defect that must be logged.

Information should not be conveyed by color alone. For example, if a form field is marked as invalid only by turning the border red, a colorblind user may not notice. Check that error messages include an icon or text in addition to color.

Similarly, links should be distinguishable from surrounding text not only by color but also by underlining or another visual cue. If a link is only differentiated by color, it fails the acceptance criteria.

When testing, use a color contrast analyzer tool to get precise ratios. Record the exact colors and the contrast ratio in your defect log. Also test in grayscale mode to see if any information is lost when color is removed.

This helps identify issues where color is the only differentiator.

### Defect Logging Template

When you find a defect, log it immediately using a standardized template. This ensures that all issues are documented consistently and can be easily tracked and retested. Below is a template with the required fields.

Fill in each field for every defect you find.

Use this template to document every defect, no matter how small. This will help your development team understand the issue and verify the fix.

Remember to include the environment details, as some issues may only occur in specific browsers or with certain assistive technologies.

Forms and Input Assistance

Forms are a primary interaction point for users, and inaccessible forms block task completion. Acceptance testing must verify that every form control is perceivable, operable, and understandable.

Start by checking that each input, select, and textarea has an associated label. Use the W3C evaluation guidance that combines automated checks with manual inspection to confirm labels are programmatically linked, not just visually placed (evidence_pack O2).

For each field, inspect the code to ensure the `for` attribute matches the input’s `id`, or that the label wraps the control. If a label is missing, assistive technology announces the field as "edit" with no purpose, failing the acceptance criterion.

Error messages must be programmatically associated with their inputs. Verify that each error message is linked via `aria-describedby` to the relevant field. When a user submits an invalid form, the error message should be announced by screen readers.

Test this by triggering a validation error and listening with a screen reader to confirm the message is read. Also, ensure that required fields are clearly indicated.

Do not rely on color alone; use an asterisk with a textual note or an `aria-required` attribute. The indication must be perceivable by all users, including those using screen readers or color-blindness simulators.

A form error summary at the top of the page helps users understand what went wrong. Acceptance requires that this summary is announced by screen readers when it appears. Use an `aria-live` region or move focus to the summary.

Test that the summary lists all errors and that each error links to the corresponding field. For complex forms, consider grouping related fields with `fieldset` and `legend` to provide context. Verify that the legend is announced before the group’s fields.

Keyboard operability is essential. Tab through the form in a logical order, ensuring that all interactive elements receive focus and that the focus order matches the visual layout.

Test that dropdowns, radio buttons, and checkboxes can be operated with arrow keys and spacebar. For custom widgets, ensure they implement expected keyboard patterns.

Also, check that the form can be submitted using the Enter key from any text field, unless that would cause unintended submission.

Finally, verify that autocomplete attributes are used where appropriate, such as for name, address, and email fields. This helps users with cognitive disabilities and speeds up form completion.

Acceptance tests should include a mix of automated tools and manual checks, as recommended by W3C evaluation approaches (evidence_pack O2). Document any failures with the defect logging template provided later.

Alternative Text and Multimedia

Non-text content must have text alternatives that convey the same information. Acceptance testing begins with a review of all images. Informative images, such as charts, diagrams, or photos that illustrate content, must have descriptive alt text.

The alt text should be concise but complete, conveying the essential information. For example, a bar chart showing quarterly sales should have alt text that summarizes the trend, not just "chart."

Decorative images, such as spacers or purely aesthetic graphics, must have empty alt attributes (`alt=""`) so that screen readers skip them. If an image is within a link, the alt text should describe the link’s destination, not the image itself.

Videos must have captions or transcripts. Captions provide synchronized text for audio content, benefiting deaf or hard-of-hearing users. Transcripts are text versions of the video’s audio and visual content, useful for those who cannot watch the video.

Acceptance testing should verify that captions are accurate and synchronized. For audio content, such as podcasts, provide a text transcript. Check that the transcript is accessible and located near the media player.

For complex images like infographics, consider providing a long description or a link to a text alternative. Test that the alternative text is announced by screen readers in the correct order.

Also, ensure that images that convey information are not used solely for visual effect. If an image contains text, that text must be present in the alt text or in the surrounding content.

Multimedia players must be keyboard accessible. Verify that play, pause, and volume controls can be operated with the keyboard. Also, ensure that the player does not automatically start playing with sound, as this can disorient users.

If autoplay is used, provide a way to pause or stop it. Acceptance tests should include checking that captions can be toggled on and off. Use the W3C guidelines as a reference for testable criteria (evidence_pack O1).

Document any missing or inadequate text alternatives as defects.

Dynamic Content and State Changes

Dynamic content updates, such as AJAX-loaded results, modal dialogs, and live regions, must be perceivable by assistive technologies. Acceptance testing should verify that when content is updated dynamically, screen reader users are notified.

Use `aria-live` regions for content that updates without user interaction, such as stock tickers or chat messages. Test that the live region is announced appropriately.

For example, a polite live region should not interrupt the user, while an assertive region may be used for critical alerts.

When a modal dialog opens, focus must move into the dialog, and when it closes, focus must return to the triggering element. Test this by opening a modal and checking that the focus is trapped within it, and that tabbing cycles through the dialog’s controls.

Also, ensure that the modal has an accessible name and that its content is announced. When closing, verify that focus returns to the button that opened it, preserving the user’s context.

Carousels and sliders must be pausable and have alternative navigation. Users with vestibular disorders may be affected by auto-rotating content. Acceptance requires that carousels can be paused using keyboard controls or a visible pause button.

Also, provide alternative navigation, such as previous/next buttons or slide indicators, that are keyboard accessible. Test that the carousel does not auto-advance when the user is interacting with it.

Loading states must be announced. When content is being fetched, provide a visual indicator and an `aria-busy` attribute on the container. Screen readers should announce that content is loading. Once loaded, the live region should announce the update.

Test this by simulating a slow network and verifying the announcement. Also, ensure that dynamic changes do not cause unexpected page jumps or loss of focus. Use the W3C evaluation methods to combine automated and manual testing (evidence_pack O2).

Document any issues with the defect template.

Defect Logging and Retesting

A standardized defect logging template ensures that accessibility issues are documented consistently and can be retested effectively.

The template should include the following fields: Defect ID, Title, Page URL, Steps to Reproduce, Expected Result, Actual Result, Severity, Screenshot, Environment, and Retest Status. Each defect should be uniquely identified for tracking.

The title should be concise and descriptive, such as "Focus cannot move into modal." The page URL should be the exact location where the issue occurs.

Steps to reproduce should be detailed enough for a developer to replicate the issue, including the assistive technology used.

Expected result describes what should happen according to accessibility standards, while actual result describes what actually happens. Severity should be rated as Critical, Major, Minor, or Cosmetic, based on the impact on users.

A screenshot or screen recording provides visual evidence. Environment includes browser, operating system, and assistive technology versions. Retest status tracks whether the defect has been fixed and verified.

After a developer fixes a defect, the QA team must retest. The retest process involves reproducing the original steps to confirm the issue is resolved. Update the Retest Status to "Pass" or "Fail" based on the outcome.

If the fix introduces new issues, log a new defect. Retesting should be performed in the same environment as the original report, but also in other supported environments to ensure compatibility.

Use the W3C evaluation guidance to ensure that retesting includes both automated and manual checks (evidence_pack O2). Maintain a log of all defects and their statuses for reporting to stakeholders.

This template provides a structured approach to tracking accessibility issues, ensuring that no defect is overlooked and that all are resolved before release.

Next step

Download the defect logging template and start acceptance testing