Thanks to a generous grant from the InVision Design Forward Fund, we're in the process of redesigning the site. You can follow along with our plan on GitHub, and review our purpose and team. Interested in helping out? Check out our contributing guidelines.
Your future self, coworkers, and most importantly customers and clients will thank you for developing with accessibility in mind.
Tech debt goes down when accessibility goes up
The best way to future proof your accessibility efforts is to ensure websites and applications are built with a foundation in proper HTML semantics. We can help ensure we are future-proofing our project by following two rules from Web Content Accessibility Guidelines (WCAG): Parsing and Name, Role, Value.
Following these rules has the bonus value of better supporting current and future browsers and other user agents, while additionally ensuring assistive technologies (AT) such as screen readers will be more likely to correctly interpret the content of our projects.
Breaking down the rules
Let’s define the WCAG rules and look at some quick tips to help follow them.
Following this rule helps ensure that browsers and AT will be able to correctly interpret your web interface without complications from poorly-structured markup.
- The W3C Nu HTML Checker can help you locate errors in your source or rendered markup. Any reported validation can be corrected, which will help decrease the likelihood of ATs incorrectly parsing your website.
- Follow the official HTML specifications for guidance on writing correct markup. Some quick tips: make sure to close open tags (
<div class="a-class">...</div>), use unique
ids, and don’t incorrectly nest HTML elements.
4.1.2 Name, role, value
This rule is related to the components and controls that make up the web interface. It helps to ensure components can have their name and role programmatically determined, and that their states, properties, and values can be set by the individual interacting with them.
All standard HTML controls already meet these rules by default. The guideline is primarily aimed at developers that heavily redesign or modify the functionality of standard HTML controls, or design and/or script their own interface components and controls from scratch.
While these are only two of the criteria to follow to make your website more accessible, they should take a prominent spot in every web developer’s workflow.
Additionally, the use of checklists, such as The A11y Project checklist, can help you future-proof your accessibility efforts.