Skip To main content

Understand your digital accessibility & compliance status | Explore resources

Coding with Accessibility in Mind

Developers play a key role in making websites and other digital assets accessible. Many accessibility requirements are technical and within the code itself. As soon as you begin writing code, it’s critical to incorporate accessibility standards following the Web Content Accessibility Guidelines (WCAG) 2.1 AA technical requirements.

While there are 50 WCAG success criteria in WCAG 2.1 AA, if you start by focusing on just a few key improvements, you’ll make a significant impact on the accessibility of your website and other digital assets.

Associate a label with every form control.

With a form label, users know what input information to provide. Ensure enough information is included so the user can input the expected information without confusion.

WCAG success criterion 3.3.2

Pointer input should be reversible.

Add a cancel and/or abort option, which means the user can move their mouse or finger to somewhere else and release with no effect. Another option is to actually provide the ability to undo the action or confirm they want to proceed with the action. This could be as simple as a confirmation pop-up.

WCAG success criterion 2.5.2

Identify page language and language changes.

With clearly identified page language, both conventional users and screen reader users can understand the text more accurately. The same goes for if the language changes–say from English to Spanish–different points in a document.

WCAG success criterion 3.1.1

Structure information and relationships.

Structure your website so that content is read by a screen reader in the same way it’s presented visually. A good example is proper coding for headings.

WCAG success criterion 1.3.1

Establish proper reading order.

Setting the reading order allows screen readers or text-to-speech technologies to read the information in a logical order. If information in the form of tables, figures and charts, for example, isn’t properly marked, a person using various assistive technologies may lose track of where they are in a document.

WCAG success criterion 1.3.2

Visual and programmatic labels should align.

Some buttons, form fields, selectors and other interactive elements may have a programmatic label (label that is inside the code) that is slightly different from what visually shows on the website. One alternative to the exact same label is to start the label and text off with the same few words.

WCAG success criterion 2.5.3

Provide meaning for non-standard interactive elements.

Use WAI-ARIA to provide information on function and state for custom widgets, such as accordions and custom-made buttons.

WCAG success criterion 4.1.2

Ensure that all interactive elements are keyboard accessible.

To be considered fully accessible, web content must be navigable by someone using only the tab key on a keyboard, ensuring proper keyboard focus.

WCAG success criterion 2.1.1

Avoid CAPTCHA where possible.

CAPTCHAs can be difficult for all users, especially people with disabilities, so determine if there is an alternative way you can filter out spam, bots, etc.

WCAG success criterion 1.1.1

More WCAG success criteria for developers

  • Designers
  • Developers

3.2.6 Consistent Help (Level A)

In the world of web accessibility, consistency is key. To provide an inclusive experience, websites must be designed in a cohesive and predictable way—and that...
  • Authors
  • Developers

3.1.2 Language of Parts (Level AA)

If the language of a page or parts of a page is different from the default language of the website, the change needs to be...
  • Authors
  • Developers

1.4.13 Content on Hover or Focus (Level AA)

This criterion addresses when receiving and then removing pointer hover or keyboard focus trigger additional content to become visible and then hidden.
  • Developers

Understanding WCAG 2.5.1 Pointer Gestures 

Provide a single activation point alternative to complex touch activation, for example swiping, pinching, etc.
  • Developers

Understanding WCAG 3.3.2 Labels or Instructions

For any element that requires user input or action, provide concise labels and/or instructions.
  • Developers

Understanding WCAG 2.5.2 Pointer Cancellation 

Pointer input should be reversible.
  • Developers

Success Criterion 3.3.9 Redundant Entry (Level A)

For steps in a process such as registering or completing a form, information that the user has already entered must be made available to them. In...
  • Developers

3.3.8 Accessible Authentication – No Exception (Level AAA)

If your website authentication requires a cognitive function test, make sure it has an alternative that doesn’t have such a test. What you need to...
  • Developers

3.3.7 Accessible Authentication (Level AA)

A cognitive function test to log in can only be required under limited circumstances. What you need to know What you need to do
  • Developers

2.5.8 Target Size – Minimum (Level AA)

All interactive targets should take up at least 24×24 CSS pixels of space. This can include white space around the target. What you need to...
  • Developers

2.5.7 Dragging Movements (Level AA)

If any part of your website requires a dragging movement, provide an alternative means of dragging, such as tapping or clicking. What you need to...
  • Developers

2.4.13 Focus Not Obscured – Enhanced (Level AAA)

When a user interface component receives keyboard focus, the focus indicator may not be hidden by author-created content. This is the AAA level of SC...
  • Developers

2.4.12 Focus Not Obscured – Minimum (Level AA)

When a user interface component receives keyboard focus, the component and its focus indicator may not be completely hidden or cut off. What you need...
  • Developers

3.1.5 Reading Level (Level AAA)

What you need to know People with reading disabilities such as dyslexia may have trouble comprehending content that is not clearly written. Clear, straightforward writing...
  • Developers

4.1.3 Status Messages (Level AA)

For any status messages that do not receive focus, programmatically provide a way to alert users.
  • Developers

2.5.4 Motion Actuation (Level A)

Functionality that is activated by device or user motion, for example, shaking a device or signaling to a camera, should be able to be disabled...
  • Developers

2.1.4 Character Key Shortcuts (Level A)

Provide a way to adjust the activation of keyboard shortcuts.
  • Designers
  • Developers

1.4.11 Non-text Contrast (Level AA)

Make sure you have a minimum 3:1 color contrast ratio for user interface components and states and graphical objects that convey meaningful information.
  • Developers

1.3.5 Identify Input Purpose (Level AA)

Make it possible to autocomplete input fields.
  • Developers

4.1.2 Name, Role, Value (Level A)

For all user interface components (e.g. forms, links, scripts, controls, etc.), the name and role of those components should be coded in. Any states, properties,...
  • Developers

4.1.1 Parsing (Level A)

Make sure your website uses correct markup and is free of errors that may create usability problems.
  • Designers
  • Developers

3.3.4 Error Prevention – Legal, Financial, Data (Level AA)

Provide ample opportunity for users to review and correct any potential errors, especially those that may have a big impact.
  • Designers
  • Developers

3.3.3 Error Suggestion (Level AA)

Make suggestions on how to fix form errors if an input error is automatically detected.
  • Developers

3.3.1 Error Identification (Level A)

When any input error is automatically detected, alert the user, describe the error, and provide instructions on how to correct it.
  • Developers

3.2.2 On Input (Level A)

Nothing on a website should automatically change just because a user inputs text, checks a box, or navigates down a drop-down box.
  • Designers
  • Developers

3.2.1 On Focus (Level A)

Nothing on a website should automatically change just because it receives focus.
  • Developers

3.1.1 Language of a Page (Level A)

Set the default language for each page of your website in the code.
  • Developers

2.4.7 Visible Focus (Level A)

When an interactive element (link, button, form field, selectable element, etc.) receives focus, a visual indicator should show so the user can see what element...
  • Developers

2.4.3 Focus Order (Level A)

When users tab through your website the interactive elements should receive focus in a logical order.
  • Developers

2.4.1 Bypass Blocks (Level A)

Provide the ability to skip past your header (with menu, navigation, ads, etc.) and go directly to the main content of your website.
  • Designers
  • Developers

2.3.1 Three Flashes or Below Threshold (Level A)

Nothing on a webpage should flash more than three times in a second.
  • Designers
  • Developers

2.1.2 No Keyboard Trap (Level A)

Keyboard-only users must be able to navigate to and from all parts of a website. No mouse should be necessary to move away from any...
  • Developers

2.1.1 Keyboard (Level A)

Your website must be fully accessible using only a keyboard.
  • Designers
  • Developers

1.4.4 Resize Text (Level AA)

All text on your website should be able to be resized up to 200% without any loss of content or functionality on your website.
  • Developers

1.3.2 Meaningful Sequence (Level A)

Structure your website so that your content is presented in a logical order.
  • Designers
  • Developers

1.3.1 Info and Relationships (Level A)

Structure your website so that content is read by a screen reader in the same way it's presented visually.