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


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 to know Among other users, people with ADHD or cognitive disabilities can benefit from always having the focus indicator visible to them. A focused element that’s hidden behind other page […]


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 2.4.12 (AA). This success criterion requires that none of the focus indicator is hidden. What you need to know Among other users, people with ADHD or cognitive disabilities can benefit […]


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


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


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 know This requirement doesn’t apply to actions that are necessary to operate the user agent or assistive technology. Dragging does not require a particular path, only a starting and an […]


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 know Ensuring that targets are big enough and that there’s sufficient space between them makes it less likely that a user will accidentally activate the wrong control.  Meeting this success […]


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.6 Consistent Help (Level A)


If you have a help option, make sure it’s consistently available and in the same relative place on each page. This will make it easy to find as users navigate your website. What you need to know Access to help mechanisms may be provided directly on the page or may be provided by a link […]


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 According to W3C, a cognitive function test is a task that “requires the user to remember, manipulate, or transcribe information.” This could take the form of a username and password, doing calculations, or solving a puzzle.  […]


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 know The AA success criterion 3.3.7 allows authentication by using object or content recognition (for example, check every box with a traffic light), but 3.3.8 level AAA doesn’t.  Common identifiers […]


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


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 a nutshell, this success criterion helps users by not making them enter information more than once unless it’s absolutely necessary.