Use these 60 concepts to connect accessibility requirements with practical implementation and evaluation decisions. Each concept includes a resolved example and a specific mistake to avoid. Begin with standards and semantics, then apply those foundations to user interaction, dynamic interfaces, testing, and organizational practice.
Standards and accessibility foundations
1. Identify barriers through the task
Accessibility barriers arise from the interaction between a person's abilities, technology, and interface demands. Identify what a task requires rather than assuming every person with the same disability uses the same tools. A barrier may affect several groups, while a solution for one barrier may leave another unresolved.
Worked example: A drag-only planner excludes someone using a keyboard. Adding Move earlier and Move later buttons provides an alternative without requiring precise dragging.
Mistake to avoid: Assuming screen reader support alone addresses every accessibility need.
Source reference: Home | Web Accessibility Initiative (WAI) | W3C; WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
2. Use the four WCAG principles diagnostically
WCAG organizes accessibility under perceivable, operable, understandable, and robust principles. These help explain why a barrier matters: information must be available, controls usable, meaning and behavior understandable, and content interpretable by relevant technologies. A single defect can implicate more than one principle.
Worked example: An unlabeled checkout button creates an understandable problem because its purpose is unclear and a robust problem when its name is unavailable to assistive technology.
Mistake to avoid: Treating the principles as four independent tests that replace success criteria.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
3. Separate principles, guidelines, and success criteria
Principles express broad goals; guidelines organize those goals; success criteria provide testable requirements. An evaluation needs the applicable success criterion and evidence about the implementation. A general claim that a page is understandable does not establish whether its labels, instructions, or error handling satisfy particular requirements.
Worked example: A report about an unnamed input identifies the relevant labeling requirement and records what the input exposes, instead of merely citing the understandable principle.
Mistake to avoid: Reporting a broad guideline as though it supplied a complete pass-or-fail procedure.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
4. Understand cumulative conformance levels
WCAG success criteria have levels A, AA, and AAA. A higher conformance level includes the requirements of the lower levels; it is not an average performance score. Evaluation also depends on the specified version and conformance scope. Meeting selected higher-level criteria does not compensate for an applicable lower-level failure.
Worked example: A site meets several AAA criteria but has an applicable Level A keyboard failure. Those additional successes do not establish Level AA conformance.
Mistake to avoid: Calculating conformance by the percentage of successful checks.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
5. Distinguish published standards from drafts
Published WCAG Recommendations provide stable reference points. Draft work can introduce proposals without establishing a finished requirement. Always identify the version governing an evaluation or contract. The existence of a newer publication or draft does not, by itself, change the version named in another requirement.
Worked example: A contract names WCAG 2.1. An evaluator reports against that target and separately notes useful improvements associated with later guidance.
Mistake to avoid: Treating a WCAG 3 draft proposal as an established WCAG 2 requirement.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C; Home | Web Accessibility Initiative (WAI) | W3C
6. Distinguish requirements from supporting techniques
WCAG success criteria establish requirements, while techniques and Understanding documents help interpret and implement them. A technique can be useful without being the only acceptable solution. Evaluate the resulting accessibility against the criterion and its conditions, rather than enforcing one preferred coding recipe.
Worked example: Two forms associate visible labels with inputs through different valid mechanisms. The evaluator checks whether both expose accurate names and usable relationships.
Mistake to avoid: Failing an implementation solely because it differs from a familiar technique.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
7. Separate technical standards from legal obligations
WCAG is a technical accessibility standard. Legal or contractual obligations depend on the applicable jurisdiction, organization, service, and governing instrument. A standard's publication does not automatically establish who must follow it. Confirm the actual obligation before interpreting a technical finding as a legal conclusion.
Worked example: A supplier agreement specifies a WCAG target. The reviewer evaluates that target and refers questions about statutory duties to qualified legal guidance.
Mistake to avoid: Claiming that one WCAG version is legally mandatory for every website worldwide.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
8. Recognize the accessibility ecosystem
Accessible experiences depend on content, authoring tools, browsers, assistive technologies, and their interaction. WCAG addresses content; related WAI guidelines address authoring tools and user agents. Identify the layer responsible for a failure before choosing a remedy, while still investigating whether content can avoid or mitigate the barrier.
Worked example: An editor removes label associations during saving. The team corrects the authoring tool behavior and repairs affected published forms.
Mistake to avoid: Assuming every accessibility failure originates in the user's assistive technology.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C; Home | Web Accessibility Initiative (WAI) | W3C
Accessible content, structure, and visual design
9. Write image alternatives for their purpose
An image's alternative should convey its role in context. Informative images need equivalent information; functional images need the action or destination; purely decorative images should not add unnecessary announcements. The same picture can require different treatment depending on its surrounding content and use.
Worked example: A magnifying glass inside a search button receives the functional name Search. The same illustration beside an already labeled search field can be decorative.
Mistake to avoid: Describing a functional image's appearance while omitting its action.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
10. Provide equivalents for complex graphics
A short alternative identifies a chart or diagram, but complex information often needs an adjacent explanation or structured data. Preserve the relationships and conclusions users need, not merely a list of visual elements. Choose a format that supports the same task as the graphic.
Worked example: A chart shows returns falling from 40 to 25. Its text explains the decline of 15, and an accompanying table supplies each month's value.
Mistake to avoid: Using the alternative Sales chart when the chart contains essential findings.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
11. Express document structure semantically
Headings identify sections, while landmarks identify major page regions. Their semantics support navigation independently of visual formatting. Choose heading levels to express relationships and give repeated region types useful distinctions when needed. Large or bold text alone does not expose a heading relationship.
Worked example: A service page uses one main heading, subordinate headings for Eligibility and Application, and a main region containing the service content.
Mistake to avoid: Selecting heading levels only to obtain a preferred font size.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
12. Make link purpose understandable
Link text and its available context should let users determine where a link leads or what it provides. Repeated vague labels create unnecessary investigation, especially when users navigate links separately from surrounding prose. Also distinguish navigation to another resource from an action performed on the current interface.
Worked example: Two links labeled Details become Delivery details and Return details, allowing users to choose the relevant destination.
Mistake to avoid: Giving different destinations identical vague names when useful context is unavailable.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
13. Associate table cells with headers
Data tables communicate relationships between values and their row or column headers. Use table semantics and appropriate header associations so those relationships remain available without visual alignment. Complex tables may need explicit associations or simplification. Layout arrangements should not acquire misleading data-table semantics.
Worked example: In a fares table, the value 18 is associated with the row Adult and the column Weekend, making its meaning recoverable.
Mistake to avoid: Styling the first row as bold text without exposing it as headers.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
14. Give inputs persistent, associated labels
An input needs an accessible name that communicates its purpose. A visible, programmatically associated label helps visual users, assistive technology users, and people returning to a completed field. Placeholder text is unreliable as the sole label because it can disappear and does not consistently provide the needed relationship.
Worked example: An address field retains the visible label Street address after entry, with the label associated with that specific input.
Mistake to avoid: Using an example address inside the field as its only identification.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
15. Label groups as well as individual controls
Related controls may need a shared question or instruction in addition to individual names. Group semantics preserve that relationship for users navigating one control at a time. Each option should remain identifiable, and the group label should explain what choosing an option means.
Worked example: Radio buttons named Email and Telephone sit in a group labeled Preferred contact method. The shared question makes each option's role clear.
Mistake to avoid: Repeating Choose one for every option while omitting the actual group question.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
16. Identify errors and explain recovery
Error handling should identify the affected field, explain the problem in text, and provide a useful correction when one is known. Preserve valid information so users can recover efficiently. Connect field-level messages to their inputs, and make any error summary support locating the problems.
Worked example: After submission, a date field reports Enter a real calendar date; 31 April is invalid. Other valid entries remain intact.
Mistake to avoid: Showing only a red border or clearing the entire form after one error.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
17. Avoid instructions that depend on one sense
Instructions should identify controls through information available across relevant presentation modes. Position, shape, sound, or color can supplement an instruction, but should not carry essential meaning alone. Give users names or text that remain useful when layout changes or sensory information is unavailable.
Worked example: Select the green box on the right becomes Select Confirm delivery. The button retains that visible and accessible name.
Mistake to avoid: Assuming left and right remain meaningful after responsive content rearranges.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
18. Calculate contrast from relative luminance
Contrast ratio uses relative luminance, not an informal judgment that colors look different. The calculation is the lighter luminance plus 0.05 divided by the darker luminance plus 0.05. Compare the result with the applicable requirement, accounting for the content type and relevant exceptions.
Worked example: For supplied luminances of 0.80 and 0.10, the ratio is 0.85 divided by 0.15, approximately 5.67:1.
Mistake to avoid: Substituting raw RGB channel values directly for relative luminance.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
19. Support enlargement and flexible layout
Text enlargement and narrower viewports can expose clipping, overlap, and reading-order problems. Flexible layouts should preserve content and functionality while adapting to available space. Some content, such as a genuinely two-dimensional data table, needs special handling; that does not justify making the entire page rigid.
Worked example: At a narrow viewport, account cards stack vertically and their action buttons remain reachable. A wide data table has its own scrolling region.
Mistake to avoid: Fixing container heights so enlarged text disappears behind adjacent content.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
20. Caption meaningful audio in video
Captions present audio information as synchronized text. They include spoken words and meaningful non-speech information needed to understand the content. Timing, speaker identification, and accuracy affect usefulness. Requirements depend on the media type and applicable criterion, so identify whether content is live or prerecorded.
Worked example: A training clip captions the instructor's speech and identifies an offscreen alarm that causes the demonstrated evacuation.
Mistake to avoid: Captioning dialogue while omitting an essential warning sound.
Source reference: Home | Web Accessibility Initiative (WAI) | W3C; WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
21. Distinguish audio description from transcripts
Audio description communicates important visual information that the existing audio does not convey. A transcript provides a separate text representation; a descriptive transcript also includes relevant visual information. These formats support different uses and are not automatically interchangeable under every accessibility requirement.
Worked example: A silent demonstration changes a gauge from Safe to Overload. Description communicates that change, while a descriptive transcript records it alongside the spoken explanation.
Mistake to avoid: Assuming captions communicate visual events that never appear in the audio.
Source reference: Home | Web Accessibility Initiative (WAI) | W3C; WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
22. Make wording and behavior predictable
Clear instructions, consistent control names, and predictable behavior reduce avoidable comprehension demands. Explain necessary specialized terms and announce consequential behavior before users trigger it. Changing a field value should not unexpectedly redirect users or remove their current context.
Worked example: A shipping selector updates the displayed cost, while a separately labeled Continue button advances to payment. Users can inspect the change first.
Mistake to avoid: Automatically navigating away as soon as someone selects a shipping option.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
Assistive technology and input interaction
23. Understand the accessibility tree
Browsers expose accessibility information derived from document semantics, styles, and accessibility attributes. Assistive technologies use that information to interpret controls and relationships. Visual appearance and source markup alone do not establish what users receive; inspect the exposed role, name, state, and structure.
Worked example: A styled square looks like a checkbox, but the accessibility tree exposes plain text. A native checkbox restores the missing control semantics.
Mistake to avoid: Assuming a convincing visual imitation creates an accessible control.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
24. Distinguish reading navigation from focus navigation
Screen readers can navigate document content by headings, landmarks, links, or reading commands, while keyboard focus targets interactive elements. These navigation methods overlap but are not identical. Static text should usually remain readable without becoming an extra stop in the interactive focus sequence.
Worked example: A help paragraph is available through screen reader reading navigation, while Tab moves directly between the surrounding form controls.
Mistake to avoid: Making every paragraph focusable to ensure a screen reader can find it.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
25. Match keyboard activation to the control
Keyboard users need to reach and operate controls without a pointer. Expected keys depend on the control type: native buttons and links already supply appropriate behavior, while custom widgets require deliberate implementation. Pointer event handling alone does not provide equivalent keyboard operation.
Worked example: A Save action uses a native button, allowing activation through the button's standard keyboard behavior as well as a pointer.
Mistake to avoid: Adding a click handler to a generic element and assuming it behaves like a button.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
26. Keep focus order meaningful
Sequential focus should follow an order that preserves meaning and operability. Document order is usually the simplest foundation. Visual rearrangement can create confusing jumps when it diverges from focus order. Positive tabindex values introduce a separate ordering system that becomes difficult to maintain.
Worked example: A booking form places departure, destination, date, and Search in a logical document sequence, which remains coherent when the layout stacks.
Mistake to avoid: Repairing each layout change with increasingly large positive tabindex values.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
27. Keep focused controls visibly identifiable
A focus indicator tells keyboard users which control will receive their action. It must remain discernible against its surroundings, and the focused control must be usable despite overlays or sticky content. Check actual states, including focus near viewport edges and after scrolling.
Worked example: A sticky footer covers the focused Submit button. Adjusting layout space and scrolling behavior brings the button and its focus indicator into view.
Mistake to avoid: Removing focus outlines because the unfocused design appears cleaner.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
28. Distinguish intentional containment from keyboard traps
A keyboard trap prevents users from leaving an area through an available, understandable keyboard method. Modal dialogs may intentionally contain focus while open, but need a usable dismissal or completion path. Nonstandard exit methods require clear instructions rather than hidden knowledge.
Worked example: A modal keeps Tab within its controls and provides a keyboard-operable Close button that returns focus to the opener.
Mistake to avoid: Containing focus in a widget without any discoverable way to leave it.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
29. Provide alternatives to demanding pointer gestures
Path-based gestures, multipoint gestures, and dragging can exclude users who cannot perform them reliably. Provide simpler controls where the applicable requirement calls for an alternative, while respecting essential-function exceptions. Also avoid triggering irreversible actions merely because a pointer was pressed.
Worked example: A map supports pinch zoom and also supplies Zoom in and Zoom out buttons. Users can change scale without coordinating two fingers.
Mistake to avoid: Assuming a keyboard shortcut alone solves every touch interaction barrier.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
30. Align visible labels with speech input
Speech input users often identify controls by saying their visible labels. An accessible name that excludes or contradicts that text can make targeting difficult. Preserve the visible label within the accessible name, and avoid unnecessary naming overrides that replace recognizable wording.
Worked example: A visible button labeled Send message keeps Send message in its accessible name rather than being renamed Dispatch correspondence.
Mistake to avoid: Improving a hidden name while making it inconsistent with the visible control.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
31. Control time limits and distracting motion
Time limits and automatically moving content can interfere with reading and interaction. Identify whether users can extend, stop, pause, or otherwise manage the behavior, subject to the applicable requirement and its exceptions. Reducing decorative motion does not by itself resolve an expiring task.
Worked example: A rotating announcement panel provides Pause. Separately, an expiring form warns users and offers an extension when permitted by the task.
Mistake to avoid: Treating a reduced-motion setting as a complete solution to time limits.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
32. Evaluate mobile assistive interaction
Mobile screen reader gestures often move an accessibility cursor or activate the selected control rather than reproducing ordinary touch behavior. Interfaces must expose meaningful targets, states, and reading order. Desktop keyboard operation is valuable evidence, but cannot establish whether mobile assistive interaction works.
Worked example: A mobile filter panel exposes each option and its selected state, allowing a screen reader user to inspect and activate options without dragging the panel.
Mistake to avoid: Concluding that mobile accessibility passes because desktop Tab navigation works.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
ARIA and dynamic interface behavior
33. Prefer native semantics when they fit
Native controls provide semantics and substantial interaction behavior together. ARIA can describe custom interfaces, but does not automatically supply keyboard operation, focus management, or visual states. Choose a native element when it represents the intended function, then customize presentation without discarding its behavior.
Worked example: A download action uses a link to the file. A panel toggle uses a button, avoiding custom reimplementation of both control types.
Mistake to avoid: Replacing a suitable native button with a generic element solely for styling.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
34. Keep role, name, and state consistent
A role identifies the kind of object, a name identifies the particular object, and states communicate its current condition. These must agree with the actual interface. Assigning a role creates expectations that the implementation must fulfill; it does not transform behavior by itself.
Worked example: A custom checkbox named Receive reminders exposes checked after selection and unchecked after deselection, matching its visible state.
Mistake to avoid: Updating the painted checkmark while leaving the exposed checked state unchanged.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
35. Resolve competing accessible names
Accessible names are computed from naming mechanisms according to rules that depend on the element and role. For many controls, a valid aria-labelledby reference takes precedence over aria-label. Inspect the computed result whenever several mechanisms coexist, especially when visible text and hidden naming attributes differ.
Worked example: A button references visible text Confirm order through aria-labelledby. Removing an obsolete aria-label simplifies the implementation while preserving the computed name.
Mistake to avoid: Assuming every available label is automatically combined into one name.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
36. Separate accessible names from descriptions
A name answers what a control is; a description supplies additional guidance or context. Keep essential identification concise and connect supplementary instructions through an appropriate description relationship. Descriptions may be presented differently across technologies, so they should not carry the control's only identification.
Worked example: A field is named Membership number and described by Find this on your welcome letter. The guidance supplements the persistent label.
Mistake to avoid: Using a long instruction paragraph as the field's only accessible name.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
37. Hide content without creating invisible controls
Visual hiding and accessibility hiding have different effects. aria-hidden removes content from accessibility exposure without preventing keyboard focus or pointer interaction. Do not apply it to focusable controls or their ancestors while those controls remain operable. Manage visibility, focusability, and semantics as a coherent state.
Worked example: A decorative icon inside a named button is hidden from assistive technology, while the button itself remains exposed and focusable.
Mistake to avoid: Applying aria-hidden to a navigation panel whose links still receive keyboard focus.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
38. Announce updates without stealing focus
Live regions can communicate meaningful updates while users continue their current task. Choose urgency carefully, keep messages concise, and avoid announcing every minor change. Establish the announcement region before updating its content, and verify actual behavior in the relevant browser and assistive technology combinations.
Worked example: After an item is added, a polite status message says Basket updated: three items. Focus stays on the Add button.
Mistake to avoid: Moving focus to every success notification or making routine updates urgent.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
39. Manage a dialog's complete focus lifecycle
An accessible modal needs a meaningful name, suitable initial focus, contained interaction while open, and a usable closing path. Background interaction must actually be restricted when modal behavior is claimed. On closing, restore focus to a logical location, commonly the opener if it still exists.
Worked example: Opening Delete draft focuses the dialog's explanatory heading. Cancel closes it and returns focus to the draft's Delete button.
Mistake to avoid: Setting aria-modal while leaving background controls reachable and active.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
40. Connect tabs with their panels
A tab interface represents a set of choices controlling associated content panels. Expose the selected tab and the relationships between tabs and panels. Implement the expected keyboard pattern consistently. Automatic selection during focus movement should only be used when panel presentation is sufficiently responsive.
Worked example: In a manual-activation interface, arrow keys move among Profile and Preferences tabs; activation selects the focused tab and displays its associated panel.
Mistake to avoid: Styling ordinary navigation links as tabs without implementing tab relationships and interaction.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
41. Expose disclosure state accurately
A disclosure control shows or hides a section without necessarily creating a modal or composite widget. A button's expanded state should match whether its controlled content is available. Keep the control's name understandable in either state, and manage any focus that would otherwise remain inside hidden content.
Worked example: A button named Delivery options exposes expanded when its section opens and collapsed when it closes.
Mistake to avoid: Changing content visibility without updating the control's expanded state.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
42. Use a coherent composite focus strategy
Composite widgets may use roving tabindex or aria-activedescendant to manage movement within a single overall interaction area. Roving tabindex moves actual focus among items; aria-activedescendant keeps focus on a container while identifying the active item. Follow the selected widget pattern and keep the active item visible.
Worked example: A toolbar uses roving tabindex: one button participates in sequential focus, and arrow keys transfer focus and that participation to another button.
Mistake to avoid: Mixing focus strategies so the visual active item and exposed active item disagree.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
Accessibility testing and diagnostic evaluation
43. Define evaluation scope before sampling
An evaluation needs a defined product boundary, target standard, and set of relevant technologies and processes. Inventory templates, components, content types, and important states before selecting representative examples. Sampling supports investigation but does not automatically justify claims about everything outside the examined material.
Worked example: An appointment service inventory includes search, booking, validation errors, cancellation, and confirmation, rather than only its landing page.
Mistake to avoid: Selecting attractive static pages while excluding essential transaction states.
Source reference: Home | Web Accessibility Initiative (WAI) | W3C; WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
44. Map findings to applicable criteria
A failure report should identify the applicable requirement, relevant conditions, and observed evidence. Similar symptoms can have different causes, and one defect can affect several requirements. Avoid assigning a criterion from a vague resemblance; explain the connection between the observed behavior and the requirement.
Worked example: A button lacks a programmatic name. The report records its exposed role and missing name, then maps that evidence to the relevant requirement.
Mistake to avoid: Assigning every screen reader issue to the same criterion without analysis.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
45. Interpret automated results conservatively
Automated tools detect some rule violations and flag other conditions for human review. They cannot determine every contextual issue, such as whether an image alternative conveys its intended purpose. Distinguish confirmed failures, review items, and untested requirements before drawing conclusions.
Worked example: A scanner confirms that an image has alternative text. Manual review finds that Decorative image fails to describe an essential evacuation diagram.
Mistake to avoid: Treating a clean scanner result as proof of WCAG conformance.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
46. Test keyboard paths through complete tasks
Keyboard testing should cover reaching, identifying, activating, and leaving controls throughout a task. Record focus order, visible focus, expected keys, and escape routes. Testing only whether Tab reaches a control misses failures in activation, internal navigation, state changes, or completion.
Worked example: A keyboard review reaches a date picker but discovers that no available key selects a date. The booking task therefore remains blocked.
Mistake to avoid: Marking keyboard access successful merely because every control receives focus.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
47. Choose assistive technology combinations deliberately
Browser and assistive technology combinations can differ in how they expose and operate an interface. Choose combinations relevant to the product's users and supported environments, and record them in findings. Investigate conflicting results rather than generalizing one observation to every platform.
Worked example: A custom selector announces its selected option in one combination but not another. The evaluator compares exposed semantics and interaction in both.
Mistake to avoid: Reporting that all screen readers fail based on one unrecorded configuration.
Source reference: Home | Web Accessibility Initiative (WAI) | W3C; WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
48. Inspect layout under enlargement and adaptation
Visual evaluation should inspect content and functionality when users enlarge text, zoom, or adjust spacing. Look for clipping, overlaps, misplaced controls, and unnecessary scrolling. Different adaptations expose different weaknesses, so one successful viewport screenshot does not establish resilient presentation.
Worked example: Increasing text spacing reveals that a fixed-height notice cuts off its final sentence. Allowing the notice to grow preserves the message.
Mistake to avoid: Testing only the default font size and widest desktop viewport.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
49. Triangulate source, exposure, and behavior
Diagnose an interface by comparing its implementation, accessibility-tree output, and user interaction. Each reveals different evidence: source indicates intent, the tree shows exposure, and interaction shows practical behavior. Agreement across these layers strengthens a diagnosis; discrepancies help locate the cause.
Worked example: Source includes an expanded attribute, but it never changes after activation. The tree and announcement remain collapsed, identifying a state-update defect.
Mistake to avoid: Stopping the investigation after finding an apparently correct attribute in source.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
50. Evaluate forms across their state transitions
Forms need evaluation before entry, during validation, after failed submission, and after success. Check whether names, instructions, errors, status updates, and focus remain useful through those transitions. Include representative invalid inputs and correction paths without unnecessarily exposing real personal information.
Worked example: A test uses an impossible date, follows the error-summary link, corrects the field, and confirms that the success message is available.
Mistake to avoid: Reviewing the empty form while never exercising validation or submission.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
51. Audit media alternatives against the content
Media evaluation requires watching or listening to the content and comparing it with its alternatives. Check caption accuracy, synchronization, speaker changes, essential sounds, and important visual information absent from the soundtrack. Also test the player's controls and access to the alternatives.
Worked example: A demonstration's captions match speech, but a silently highlighted danger zone lacks description. The audit records these as separate observations.
Mistake to avoid: Passing media solely because a caption track exists.
Source reference: Home | Web Accessibility Initiative (WAI) | W3C; WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
52. Write reproducible accessibility findings
A useful finding identifies the affected location, starting state, steps, observed behavior, expected accessible behavior, and user impact. Include relevant environment details and supporting evidence. A suggested fix can help, but should not replace a clear description of the actual defect.
Worked example: After opening Filters, press Tab from Apply. Focus moves behind the panel and its indicator disappears; keyboard users cannot identify their current control.
Mistake to avoid: Submitting a report that says only Make this accessible.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C; Home | Web Accessibility Initiative (WAI) | W3C
53. Prioritize by impact and reach
Prioritization should consider whether users can complete important tasks, whether alternatives exist, how broadly a defect appears, and how often it is encountered. Conformance level alone is not a severity ranking. A shared component defect can affect many workflows even when found on one page.
Worked example: An unusable shared payment control receives earlier remediation than an isolated redundant announcement because it blocks purchases across the service.
Mistake to avoid: Assigning urgency solely from A, AA, or AAA labels.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C; Home | Web Accessibility Initiative (WAI) | W3C
54. Retest fixes and related behavior
Retesting should reproduce the original failure and verify that the remedy resolves it in the relevant states and environments. Also inspect closely related behavior that the change could disrupt. Regression checks are strongest when they preserve a meaningful user task rather than merely asserting a particular implementation detail.
Worked example: After repairing dialog focus, the evaluator confirms opening, closing, reopening, and focus return, then checks that background interaction is still restricted.
Mistake to avoid: Closing a finding because the requested attribute appears without testing behavior.
Source reference: WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
Accessibility in organizational practice
55. Translate accessibility goals into acceptance criteria
Product requirements should connect the applicable accessibility target with observable user behavior. Include important states and interactions rather than broad promises alone. Technical criteria and task-oriented acceptance conditions complement each other: one establishes the standard, while the other makes expected operation concrete.
Worked example: A search feature requires keyboard-operable filters, exposed selection states, and an available results update, all evaluated against the specified WCAG target.
Mistake to avoid: Writing Accessible as the entire acceptance criterion.
Source reference: Home | Web Accessibility Initiative (WAI) | W3C; WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
56. Share responsibility through reusable components
Accessible components can reduce repeated implementation work, but their use still requires appropriate names, content, configuration, and integration. Document what a component guarantees and what its consumers must supply. A sound component can become inaccessible when combined with conflicting focus behavior or missing context.
Worked example: A dialog component manages containment and focus return; the feature team supplies its meaningful title and chooses suitable initial focus.
Mistake to avoid: Assuming a component library guarantees accessibility for every assembled page.
Source reference: Home | Web Accessibility Initiative (WAI) | W3C; WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
57. Evaluate supplier accessibility claims
Procurement review should distinguish a supplier's claim from evidence about the exact product and configuration being purchased. Request relevant evaluation details, known limitations, and remediation commitments, then investigate important workflows. A broad standards statement does not demonstrate that a particular integration will work.
Worked example: A booking supplier claims accessibility. The buyer reviews its documented limitations and tests keyboard completion of the embedded booking flow.
Mistake to avoid: Accepting an accessibility logo as sufficient evidence for an essential service.
Source reference: Home | Web Accessibility Initiative (WAI) | W3C; WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
58. Turn findings into an actionable remediation plan
Remediation planning combines impact, affected scope, dependencies, ownership, and verification. Group repeated defects when they share a cause, but preserve representative evidence and affected workflows. Addressing a shared cause can improve many pages; unrelated symptoms should not be merged merely because they look similar.
Worked example: Missing names across toolbar buttons trace to one component. A single component repair is assigned, followed by checks on its different uses.
Mistake to avoid: Creating isolated page fixes while leaving the shared defective component unchanged.
Source reference: Home | Web Accessibility Initiative (WAI) | W3C; WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
59. Integrate accessibility into change decisions
Accessibility needs recurring responsibility across design, development, content, and release processes. Define who reviews relevant changes, what evidence is required, and how unresolved findings are tracked. Automated checks can support this process, while human evaluation remains necessary for contextual and interaction questions.
Worked example: A new checkout interaction receives design review, component checks, and manual task testing before release, with unresolved findings assigned to named owners.
Mistake to avoid: Treating accessibility as a one-time audit detached from subsequent product changes.
Source reference: Home | Web Accessibility Initiative (WAI) | W3C; WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
60. Use user feedback alongside standards evaluation
Feedback from people with disabilities reveals practical barriers and supports understanding their consequences. Standards evaluation supplies a separate framework for technical requirements. Neither replaces the other, and individual preferences should not be generalized to every user. Provide a usable reporting channel and investigate actionable details.
Worked example: A magnification user reports losing the active filter after expansion. The team reproduces the behavior and improves positioning while checking relevant requirements.
Mistake to avoid: Declaring universal accessibility because one participant completed one task.
Source reference: Home | Web Accessibility Initiative (WAI) | W3C; WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C
Sources
Source verification:
- Home | Web Accessibility Initiative (WAI) | W3C
- WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C