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.

4.1.1 Parsing

Following this rule helps ensure that browsers and AT will be able to correctly interpret your web interface without complications from poorly-structured markup.

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.

Wrapping up

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.

Further reading

Edit on GitHub