WCAG Quick Tips for Developers

We collaborated with experienced developers to come up with these top five digital accessibility issues and related tips. There are many more of course, which you can check out on W3C-Web Accessibility Initiative’s (WAI) Developing for Accessibility.   

1. Ensure keyboard accessibility

Your website must be fully accessible using only a keyboard. Everything should be accessible without using a mouse, and that includes forms, buttons, links, navigation menus, accordions, tooltips, and media players. 

People who are blind or have low vision may use screen readers and only the keyboard to navigate. In addition, not everyone has the fine motor skills to use a mouse. People with repetitive stress injuries or hand tremors, for example, may prefer to use just the keyboard to navigate your website. The ability to skip links using the keyboard can save these users a lot of time.

A few helpful tips: 

  • Unplug your mouse and make sure you can do everything on your website that you would be able to do if the mouse were plugged in.
  • Make sure you have no specific timings for individual keystrokes, for example, requiring a user to hold down a key or make multiple keystrokes within a few seconds before the keystroke is registered.
  • Ensure that content that appears when a user hovers the mouse over a particular element is coded correctly, otherwise it won’t be accessible to a user who only uses a keyboard.
  • Check these elements for keyboard accessibility: forms, submission buttons, media players and all navigation menus and submenus.

(Reference: WCAG success criterion 2.2.1 Keyboard

A young African-American man seated at a desk looking at a computer screen with his hands on a keyboard and mouse. Standing to his left is a young white man pointing to the computer screen.

2. Use semantic elements and mark-up to convey meaning and structure

Structure your website so that content is read by a screen reader in the same way it’s presented visually. Use mark-up to convey meaning and structure, and to structure headings, lists, tables, etc. Use semantic elements such as <nav> and <aside> to better structure content, and ARIA roles, which should only be used for UI that can’t be built using HTML. States and properties (such as role=”tab” and aria-expanded=”true”) provide assistive technology users the additional meaning and context to understand and use content.

At its core, this is all about making sure that all information that is conveyed visually is also conveyed programmatically. When there is a large, bold font before an article, for example, visually it’s inferred that the text is a heading that describes the subject or topic of the text that follows. However, this visual information is not conveyed to screen reader users unless you use proper HTML5 to code in a heading level–it’s only then that a heading is announced. Without the right code, screen readers and other assistive technologies can’t grasp how one content item relates to all the other content on the page.

A few helpful tips:  

  • Whether you’re making an unordered, ordered, or descriptive list, make sure it’s actually coded as a list, not simply bulleted or numbered. This enables a screen reader user to have an equivalent experience of the layout as a sighted user.
  • Use <h1> to <h6> headings to structure and organize content.
  • Make sure data cells are associated with header cells inside a table.
  • Programmatically label form fields.
  • Use landmark regions (such as <header>, <main>, <footer>) to help clearly define regions/sections of the page. 

(Reference: WCAG success criterion 1.3.1 Info and Relationships)

3. Help users avoid and correct mistakes

If a user inputs wrong or incorrectly formatted information, you need to make sure they know what they did wrong, where, and how to fix it. Instructions and error messages need to be very specific and easy to understand. This may require guidance on input formatting requirements related to, for example, how to input a date. Providing examples of the correct way to format a date (“mm-dd-yyyy” or “Month dd, yyyy,” etc.) are helpful. If a user inputs a zip code that doesn’t exist, your error message should convey exactly that. Adding a visual indicator to make it easy to find an error will also improve the UX.

A few helpful tips: 

  • Clearly identify what the error is. For example, if someone enters an incorrect email format (, identify the error (incorrect email format).
  • Preserve other form data that has already been input so the entire form doesn’t have to be filled out again.
  • Notify users that an error has occurred by announcing the error in an aria-live region or by indicating that the form control has failed (aria-invalid=”true”). You can also programmatically associate the error to the field using an aria-describedby attribute.

(References: WCAG success criteria 3.3.1 Error Identification and 3.3.3 Error Suggestion)

4. Use clear labels and form controls

While some controls are clear because of their label (for example, “Next Page” or “Submit” buttons), other controls might create confusion or problems with use if the labels are missing. For example, a screen reader or other assistive technology  might not be able to detect how to select a date if the “date” field or drop-down menu is not labeled clearly or accurately. 

Make it easy to understand what data input or action is being asked for by providing concise labels and/or instructions. A label could be “First Name.” A common example of an instruction is “All fields marked with an * are required.” Be sure to provide examples of expected input formats or structure data input so that the expected format is entered.  

A few helpful tips:  

  • Programmatically associate labels with the appropriate form fields.
  • Assign a visible label for every form field or area of user engagement/control.
  • If the control is a text input field, make sure there’s a visible text label that describes what should be entered.

(Reference: WCAG success criteria 3.3.2 Labels or Instructions) 

5. Write code that adapts to users’ needs

If a user employs zoom/magnification technology, all text on your website should be able to be resized up to 200% without any loss of content or functionality. You don’t want to have webpage content clipped because the user resized the text. 

Coding that adapts to your website isn’t limited to just font styles and sizes. Background colors, page borders, and line spacing can also affect the accessibility of your website. For many people with learning or intellectual disabilities, having the ability to customize these things will make your website more accessible. Bottom line, whether the technology in use is assistive or adaptive, websites need to be able to accommodate it.

A few helpful tips:  

  • Make sure there’s no loss of content caused by text going over the space or container allotted for it. 
  • If the ability to zoom isn’t provided but the user can increase the text size, ensure that the content is still usable when the text is resized.
  • Make sure that all the information on the page is still displayed even when a larger font is used for the text.

(Reference: WCAG success criteria 1.4.4 Resize Text)