Accessibility for Developers

Some of the most common accessibility errors are easily detectable and tend to appear multiple times per page. Simply addressing these few issues will have a significant positive impact on web accessibility. Tackle the most serious barriers and critical content first, and avoid common accessibility errors. References to success criteria in the tips below link to the relevant WCAG 2.1 guidelines. A variety of free training videos are also available to help you learn more about digital accessibility.

Top Tips for Developers

Developing for Web Accessibility

Deque University ARIA Widgets Code Library (Beta)

This code library provides examples of using ARIA and JavaScript effectively for custom widgets like dialogs, alerts, tooltips, date pickers, carousels, expand/collapse regions, aria-live regions, autocomplete, application menus, tab panels, tree views, etc.

Info and Relationships

Identify required form fields. If your form has a mix of required and non-required fields, add the aria-required=”true” attribute to each input that is required. This will identify them as required to screen reader users. Learn more about Success Criterion 1.3.1 Info and Relationships.

Resize Text

Ensure that all text on your website is still visible and legible when zoomed in, up to 200%. Containers should flow around text so nothing is obscured. Never disable scalability at the site level. Learn more about Success Criterion 1.4.4 Resize Text.

Keyboard Accessible

Test your website by navigating it with only a keyboard. Anything that can be done with a mouse must also be doable with a keyboard. Pay particular attention to search bars and submenus; never rely on hover alone to interact with elements. Learn more about Success Criterion 2.1 Keyboard Accessible.

Focus Order

DOM order should match visual order. Organize interactive elements logically to preserve meaning and structure when they are being tabbed through. If content is added dynamically into the DOM, place it immediately after the triggering event. Learn more about Success Criterion 2.4.3: Focus Order.

Focus Visible

Any element that receives focus should have a visible focus indicator. This is often a blue box surrounding the element in focus. Typically, this means not hiding or removing the default focus indicator, but be mindful of color contrast ratios when a focused element appears on certain background colors. Learn more about Success Criterion 2.4.7 Focus Visible.

Parsing

Write proper, semantic code. Use start and end tags, nest elements according to specification, keep IDs unique, and don’t duplicate attributes. Learn more about Success Criterion 4.1.1 Parsing.

Name, Role, Value

Names and labels should be programmatically associated with their form elements and links. All form inputs should have an associated label; if the label is visually hidden, use aria-label and aria-labelledby. Add the title attribute to iframe elements. Learn more about Success Criterion 4.1.2. Name, Role, Value.


Audio, Video, and Slideshows

Create accessible video and audio:


Pattern Libraries for Developers


Accessible Table Guidance

There are several techniques for creating accessible tables on websites, most of which involve CSS and sometimes a bit of JavaScript. The best approach depends on the data, the complexity of the table, the site design, etc. There isn’t a one size fits all technique.

If you’re using a framework, there may be responsive table classes already available. For example, Bootstrap has a .table-responsive class that triggers horizontal scrolling on small screens. That doesn’t address potential accessibility issues, so you would also want to make sure your table is well-constructed.

There are also interesting solutions on CodePen. This one switches table rows into a sort of card view on small screens.