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)
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.
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.
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.
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.
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.
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
- CSS-Tricks – Responsive Data Tables
- CSS-Tricks – Accessible Simple Responsive Tables
- Adrian Roselli – A Responsive Accessible Table
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.