Web Accessibility for New Devs

If you’re a software engineer in training or a newly employed junior dev and you’ve never thought about Universal Access on the web, chances are you are what society defines as an “able bodied person” and it’s time to confront the bias in your own coding.

What is ableism?

Urban Dictionary: “Ableism is the discrimination or prejudice against people who have disabilities. Ableism can take the form of ideas and assumptions, stereotypes, attitudes and practices, physical barriers in the environment, or larger scale oppression. It is oftentimes unintentional and most people are completely unaware of the impact of their words or actions.” Ableism shows up in many different ways in every day life.

How does ableism show up on the web? Does that image on your page have a properly descriptive “alt” tag for the visually impaired? Did you leave the labels off of your form inputs in favor of a more “minimalist” visual design approach? Does a function of your page time out too quickly without asking the user if they need more time to respond? Have you checked to see if the color of the text on your background has enough contrast for color blind users? Are you using “divs” all over the place instead of semantic HTML that is accessible to a screen reader? Have you spent any time at all thinking about how to people with a diverse range of hearing, movement, sight, and/or cognitive ability may access your app?

Where do I start?

The W3C Web Accessibility Initiative has extensive resources on accessibility guidelines, best practices, and information on how people with disabilities access the web. There is even a section devoted to developers. They have a handy list of easy practices for a developer to start applying right away:

• Associate a label with every form control
• Include alternative text for images
• Identify page language and language changes
• Use mark-up to convey meaning and structure
• Help users avoid and correct mistakes
• Reflect the reading order in the code order
• Write code that adapts to the user’s technology
• Provide meaning for non-standard interactive elements
• Ensure that all interactive elements are keyboard accessible
• Avoid CAPTCHA where possible

WebAIM also offers a checklist of recommendations for implementing accessibility principles and techniques.

ARIA

Accessible Rich Internet Applications (ARIA) is a set of attributes that define ways to make web content and web applications (especially those developed with JavaScript) more accessible to people with disabilities. Best practice is to use semantic HTML and select the appropriate, most descriptive elements. You may choose to add an ARIA property when there is no properly semantic tag available. For example, a progress bar is often built using a <div>. You can add a role=”progress-bar” attribute to inform the browser that this element is actually a JavaScript-powered progress bar widget. The aria-valuemin and aria-valuemax attributes specify the minimum and maximum values for the progress bar, and the aria-valuenow describes the current state of the progress bar.

You can also use an ARIA property to help assistive technology skip an element that is only used for visual display, such as:

• purely decorative content, such as icons or images
• duplicated content, such as repeated text
• offscreen or collapsed content, such as menus

The use of aria-hidden=”true” will remove the entire element from the accessibility API while role=”presentation” and role=”none” will remove the semantic meaning of an element while still exposing it to assistive technology.

If you are not including an element in the visual display, you can always use the CSS property display: none to remove it from the screen, while leaving the HTML element visible to assistive technology. For example, if you don’t want a label for an input to appear on screen, you should still include the label in your HTML file, but remove it from the design using your CSS:

HTML:
<label for=”name” class=”hidden”></label>
<input type=”text” id=”name” name=”user-name”>
CSS:
.hidden {
display: none;
}

HTML Validation

W3C provides a markup validation service to check to see if your HTML is living up to standards. This is important because using standards-compliant HTML increases the likelihood that all web browsers and assistive technologies will correctly handle your content. There are additional reasons this is a good practice:

• Validating mark-up can help in your debugging efforts
• Valid mark-up will help with future compatibility
• Properly formed HTML renders faster than HTML with errors

Color Contrast

DevTools (Chrome 65) now comes with a built in resources for checking the accessibility of your app. The Color Picker now shows you the contrast ratio of text elements. Increasing the contrast ratio of text elements makes your site more accessible to users with low-vision impairments or color-vision deficiencies.

WebAIM also offers a great color contrast checker that you can use as you’re developing the palette for your front end. Use a contrast checking tool to ensure you’re passing before you integrate your color scheme.

AXE

AXE (by deque) is a Google Chrome Extension that helps you test the accessibility of a site. Install the extension, then open the dev tools panel, navigate to the axe tab, and run an analysis. The analysis will report back on any issues it encounter.

Cypress-Axe

You can also install Cypress-Axe, which will enable you to test for accessibility issues. Using cy.checkA11y() will run axe against the document at the point in which it is called. This means you can call this after interacting with your page and uncover accessibility issues introduced as a result of rendering in response to user actions.

5 Easy things to make your next project more universally accessible:

1. Use a color contrast checker.
2. Include a label for every input (whether you keep them in the visual design or not).
3. Ensure all pictures have a descriptive alt tag.
4. Investigate each use of a div (is there a more descriptive element that could be use instead?).
5. Run an Axe Analysis and try to address (or at least note) any issues that pop up.