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.

Getting Started — Key WCAG Success Criteria for Developers

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

1.4.11 Non-text Contrast


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

Designers, Developers

1.4.4 Resize Text


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

Designers, Developers

2.1.2 No Keyboard Trap


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 element of a website.


2.4.1 Bypass Blocks


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


2.4.3 Focus Order


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


2.4.7 Visible Focus


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 they’re currently on.


2.5.1 Pointer Gestures


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


2.5.4 Motion Actuation


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 and an alternative for equivalent activation should be available.

Authors, Developers

3.1.2 Language of Parts


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 indicated in the HTML code.


3.2.2 On Input


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


3.3.1 Error Identification


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


4.1.1 Parsing


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


4.1.2 Name, Role, Value


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, and values set by the user should be able to be programmatically updated so browsers and assistive technologies recognize them and reflect those changes.