| 1. Plan | Name the audience and access needs before design starts. | Accessibility is easier when it is planned into the work instead of repaired at the end. | The project brief says the checkout must work with keyboard, screen readers, zoom, captions, and reduced motion. | The team only says 'make it accessible' with no acceptance criteria. | Review the project brief. It should mention users, standards, devices, assistive technology, and who approves accessibility. |
|---|
| 1. Plan | Choose the standard and target level. | Teams need a shared baseline for design, development, QA, procurement, and legal review. | Use WCAG 2.2 Level AA for the website release and document any AAA goals separately. | Using vague phrases like 'ADA compliant' without mapping work to testable requirements. | Confirm the requirement is written down, usually WCAG 2.2 AA, Section 508, EN 301 549, or local policy. |
|---|
| 1. Plan | Include accessibility in scope, timeline, and definition of done. | If access checks are not scheduled, they are often dropped when launch pressure rises. | Each feature ticket includes keyboard, screen reader, contrast, error handling, and responsive checks. | Accessibility is a final optional audit after code freeze. | Open project tickets. Accessibility checks should appear before launch, not only after launch. |
|---|
| 2. Design | Use clear page structure: header, navigation, main content, footer, and logical sections. | Screen reader and keyboard users need predictable regions and headings to understand the page quickly. | One main heading, clear section headings, a visible page title, and a skip link. | Large visual text is styled as a heading but coded later as plain text. | Review the design and prototype. Every major content block should have a meaningful heading or label. |
|---|
| 2. Design | Make color contrast strong enough for text, icons, borders, focus, and charts. | Low contrast blocks people with low vision, glare, aging eyesight, or color vision differences. | Body text has at least 4.5:1 contrast. Large text and important icons have at least 3:1. | Light gray text on white, pale placeholder text, or red/green status only. | Use a contrast checker on real foreground and background colors, including hover, disabled, and error states. |
|---|
| 2. Design | Never use color alone to communicate meaning. | People who cannot perceive the color difference still need the same information. | Error fields use red border, an error icon, and text that says 'Email is required'. | Required fields are only red, or chart lines are only differentiated by color. | Print in grayscale or use a color-blindness simulator. Meaning should still be clear. |
|---|
| 2. Design | Design visible focus states for every interactive element. | Keyboard users need to see where they are before activating controls. | Buttons, links, cards, menus, inputs, tabs, and custom controls all have a clear focus ring. | The design removes outlines because they look messy. | Tab through the prototype or built page. Focus should never disappear or be hidden behind sticky UI. |
|---|
| 2. Design | Make touch targets large and spaced. | People with tremors, motor disabilities, large fingers, or mobile devices need room to tap accurately. | Important controls are at least 24 by 24 CSS pixels, with enough spacing around them. | Tiny icon buttons, cramped pagination, or close buttons beside other controls. | Check target size in browser dev tools and test on an actual phone with one hand. |
|---|
| 3. Content | Write links that make sense out of context. | Screen reader users often browse links as a list, separate from surrounding paragraphs. | 'Download the accessibility checklist' instead of 'Click here'. | Multiple links on a page all say 'Read more' or 'Learn more'. | Read only the link text on the page. Each link should tell the user where it goes or what it does. |
|---|
| 3. Content | Use plain language and short instructions. | Clear content helps users with cognitive disabilities, low literacy, fatigue, translation needs, and stress. | 'Enter the 6-digit code we sent to your phone.' | 'Input verification credentials to authenticate transaction authorization.' | Ask whether a new user can complete the step without rereading. Remove jargon and split long sentences. |
|---|
| 3. Content | Write useful alternative text for meaningful images. | Alt text gives screen reader users the information carried by images. | 'Line chart showing support requests dropped from 800 to 450 after the redesign.' | 'image', 'screenshot', file names, or alt text that repeats nearby captions. | Hide the image. If the page loses meaning, write alt text that restores that meaning. |
|---|
| 3. Content | Mark decorative images as decorative. | Screen reader users should not hear noise from images that do not add information. | A decorative divider image uses empty alt text: alt="". | Screen reader announces 'blue wave background image' before every section. | Review all images. If removing the image does not change meaning, it should usually have empty alt text. |
|---|
| 4. Code | Use semantic HTML before ARIA. | Native elements already carry correct roles, keyboard behavior, and browser support. | Use <button> for actions, <a href> for navigation, <nav> for navigation, and <main> for main content. | Clickable <div> elements with role='button' but no keyboard support. | Inspect interactive elements. If a native HTML element can do the job, use it. |
|---|
| 4. Code | Keep heading levels in logical order. | Headings are the outline many users rely on to skim and jump through content. | H1 for page title, H2 for main sections, H3 for subsections. | Skipping from H1 to H4 because the H4 style looks right. | Use a heading checker or browser extension. The outline should read like a table of contents. |
|---|
| 4. Code | Add landmarks and a skip link. | Landmarks and skip links let keyboard and screen reader users bypass repeated navigation. | A visible-on-focus 'Skip to main content' link targets <main id='main'>. | Keyboard users must tab through every menu item on every page. | Press Tab once after loading the page. The skip link should appear and move focus to main content. |
|---|
| 4. Code | Give every control a programmatic name. | Screen readers and voice control software need accessible names to identify controls. | Icon-only search button has aria-label='Search'. Input has a visible <label>. | Unlabeled icon buttons announced as 'button' with no name. | Use browser accessibility inspector. Every button, input, link, and menu item should have a clear name. |
|---|
| 4. Code | Use ARIA only when it matches behavior. | Wrong ARIA can make a control more confusing than no ARIA. | A custom accordion updates aria-expanded and connects the button to its panel. | role='button' on text that cannot be focused or activated with keyboard. | Compare role, state, and keyboard behavior with the WAI-ARIA Authoring Practices pattern. |
|---|
| 5. Keyboard | Everything interactive works without a mouse. | Keyboard access supports screen reader users, switch users, power users, and people who cannot use a mouse. | Menus, dialogs, tabs, forms, sliders, and upload controls work with Tab, Enter, Space, arrows, and Escape as expected. | A custom dropdown opens with mouse but cannot be opened or closed by keyboard. | Unplug the mouse or do not touch it. Complete the main task using only the keyboard. |
|---|
| 5. Keyboard | Focus order follows visual and task order. | Unexpected focus order makes pages hard to understand and can block task completion. | Focus moves from header to search, filters, results, and pagination in the same order a sighted user reads. | Focus jumps to the footer, hidden drawer, or unrelated controls. | Press Tab repeatedly and write down the order. It should match the intended reading and action flow. |
|---|
| 5. Keyboard | Dialogs trap focus and return focus correctly. | Users should not move behind a modal by accident, and they should not lose their place after closing it. | Opening a dialog moves focus inside it. Escape closes it. Closing returns focus to the trigger. | Focus goes behind the modal or disappears at the top of the page. | Open each modal with keyboard, tab through it, close it, and confirm focus returns to the button that opened it. |
|---|
| 6. Forms | Every field has a visible label. | Labels help all users understand what information is needed and give assistive tech a reliable name. | <label for='email'>Email address</label><input id='email' type='email'> | Placeholder text is used as the only label. | Click each label. Focus should move to the matching field. Screen reader should announce the label. |
|---|
| 6. Forms | Group related radio buttons and checkboxes. | Users need the question and the available options, not just isolated choices. | A fieldset legend says 'Delivery method' with radio options 'Email' and 'SMS'. | Screen reader announces 'Email radio button' but not the question it answers. | Tab into the group with a screen reader. The group question should be announced before or with options. |
|---|
| 6. Forms | Errors are specific, visible, and connected to fields. | Users need to know what failed, where it failed, and how to fix it. | 'Password must be at least 12 characters' is linked with aria-describedby to the password field. | A red border appears with no text, or errors appear only after the user submits twice. | Submit an empty form. Focus should move to an error summary or first error, and each field should announce its error. |
|---|
| 6. Forms | Use autocomplete for common personal data. | Autocomplete helps users with memory, mobility, spelling, and cognitive load. | Use autocomplete='name', 'email', 'street-address', 'postal-code', and 'cc-number' where appropriate. | All fields have autocomplete='off' without a strong reason. | Inspect inputs and test with browser autofill or a password manager. |
|---|
| 7. Media | Videos have accurate captions. | Captions support Deaf and hard-of-hearing users, noisy environments, quiet environments, and comprehension. | Captions include speech, important sounds, speaker changes, and timing that matches the audio. | Auto-captions are published without review, punctuation, or speaker labels. | Watch the video muted. You should understand the spoken content and meaningful sounds. |
|---|
| 7. Media | Audio and video have transcripts when users need the full content. | Transcripts help users who cannot access media, prefer reading, search content, or need translation. | A webinar page includes video, captions, and a structured transcript with headings. | Only a video is provided, with no text alternative. | Try to understand the content without pressing play. The transcript should cover the same information. |
|---|
| 7. Media | Avoid flashing and give users control over motion. | Flashing can trigger seizures, and motion can cause vestibular symptoms or distraction. | Animations respect prefers-reduced-motion and carousels have pause controls. | Auto-playing sliders, parallax effects, or flashing banners with no pause. | Enable reduced motion in the operating system and reload the page. Motion should reduce or stop. |
|---|
| 8. Responsive | Page works at 200% zoom and on small screens. | Low-vision users often zoom. Mobile users and reflow requirements need content without horizontal scrolling. | At 200% zoom, text wraps, controls remain visible, and no content is cut off. | Sticky headers cover content, tables overflow, or buttons disappear. | Set browser zoom to 200% and 400%. Test key pages and forms without horizontal scrolling except for data tables. |
|---|
| 8. Responsive | Text spacing can be increased without breaking layout. | Some users need larger line height, word spacing, or letter spacing to read comfortably. | Cards and buttons expand or wrap text cleanly when spacing is increased. | Text overlaps icons, gets clipped, or disappears in fixed-height containers. | Use a text-spacing bookmarklet or accessibility toolbar and inspect headings, buttons, cards, nav, and forms. |
|---|
| 9. Documents | Downloads are accessible or have an accessible HTML alternative. | PDFs, Word files, and slide decks are content too; inaccessible documents can block users completely. | A PDF has tags, heading structure, alt text, table headers, title metadata, and logical reading order. | A scanned image PDF with no selectable text. | Try selecting text, reading tags, checking order, and running the document accessibility checker. |
|---|
| 9. Documents | Tables are only used for data and include headers. | Assistive technology needs row and column relationships to explain data cells. | A pricing table uses <th scope='col'>Plan</th> and <th scope='row'>Starter</th>. | Layout tables or data tables with bold text instead of real headers. | Navigate table cells with a screen reader. Headers should be announced with each data cell. |
|---|
| 10. Testing | Run automated scans, but do not stop there. | Automated tools catch many code issues but cannot judge every task, label, instruction, or user experience. | Use axe, Lighthouse, or a site audit tool, then perform keyboard and screen reader testing. | The team claims accessibility because Lighthouse shows 100. | Compare scan results with manual tests. Track both automated and manual findings. |
|---|
| 10. Testing | Test with at least one screen reader. | Screen reader testing reveals names, roles, state, reading order, live updates, and confusing announcements. | NVDA with Firefox or Chrome on Windows, VoiceOver on macOS/iOS, or TalkBack on Android. | Only visual QA is performed. | Complete the main task while listening. Check headings, links, buttons, forms, errors, dialogs, and dynamic updates. |
|---|
| 10. Testing | Test real tasks from start to finish. | A page can pass isolated checks but still fail the user journey. | Search product, filter results, add to cart, create account, submit payment, and receive confirmation. | Only the homepage is tested. | Pick the top user journeys and complete each with keyboard, zoom, screen reader, and mobile. |
|---|
| 11. Launch | Document issues, severity, owner, fix plan, and retest result. | Accessibility work needs accountability, not just a list of problems. | Each issue has a page, step to reproduce, user impact, WCAG mapping, owner, due date, and retest status. | Findings are stored in a PDF and never assigned. | Open the issue tracker. Every open accessibility issue should have enough detail for a developer to fix it. |
|---|
| 11. Launch | Publish a clear accessibility statement and contact path. | Users need a way to report barriers and request help. | The statement lists the conformance target, known limitations, date updated, and an email or form. | No contact route, or a statement that promises perfection without evidence. | Find the accessibility statement from the footer and submit or inspect the contact method. |
|---|
| 12. Maintain | Add accessibility checks to design review, code review, and CI. | Accessibility can regress whenever new content, components, or dependencies ship. | Pull requests include component tests, linting, contrast review, keyboard testing, and screenshot review. | Accessibility is tested once a year only. | Review recent pull requests. They should include accessibility evidence for UI changes. |
|---|
| 12. Maintain | Train authors, designers, developers, QA, and support teams. | Many barriers are created by everyday content and product decisions, not only by code. | Content authors know headings, links, alt text, captions, and document basics. | Only one accessibility specialist knows what to check. | Ask each role what accessibility checks they own. The answer should be specific and practical. |
|---|
