Accessibility: Know What You Don’t Know

Have a heart for websites everyone can use? Looking to capture a 20% market share assumed to be disabled (that’s a pretty big number when it comes to potential customers)? Perhaps you just need to check off a user story for a task delegated to you?

Regardless of the reason behind your accessibility coding journey, I am here to say it’s not as difficult as you think. The hardest part is knowing what accessibility entails and how much control you have as a developer. Actually, writing accessible code is relatively easy and will make your code cleaner and clearer for the non-accessible use cases too.

“Accessible” apps do not rely on a single sense or ability

So, what is this “A” word we keep talking about? Something that is “accessible” does not rely on a single sense or ability — it can be presented in different ways.

For example, a video alone is not accessible since it’s only output is visual information. Audio itself lacks accessibility since it relies on hearing as a singular means for consumption of information. Alternatively, a video with captions and audio would be considered accessible since it doesn’t rely on a single sense.

Know What You Don’t Know

My journey into accessibility started the way it does for most — with a Google search. After being told our app needed to be “ADA-compliant” by the higher-ups, When I jumped into research mode the frustration ensued. My findings offered no relevant search results, and government websites gave no instruction on making a compliant app. Of course, this would be the case and here’s why:

The Americans with Disabilities Act (ADA) was passed in 1990. While amendments were added over time, the ADA does not cover technology and was conceived from an even older piece of legislation — Section 504 of the Rehabilitation Act of 1973.

Talk The Regulation Talk

Here are some very, very basic summaries of regulations you need to be aware of:

• Rehabilitation Act of 1973: government and government-funded organizations cannot discriminate against individuals with a disability
• Rehabilitation Act Section 504: individuals with a disability have the right to be protected against discrimination — particularly when it comes to government and government-funded organizations
• Rehabilitation Act Section 508: government and government-funded organizations must make their technology systems (whatever that meant in 1973) accessible
• Americans with Disabilities Act: (inspired by Section 504, passed in 1990) individuals with a disability have the right to be protected against discrimination in any context — not just government funded ones — so reasonable public accommodations made to prevent discrimination
• Web Accessibility Initiative: (launched in 1997) effort to make web technology accessible to individuals with disability by providing standards called the Web Content Accessibility Guide (WCAG). While the ADA and Section 508 supporting bodies did not write the WCAG, they reference it as the modern standard of adherence

Most people don’t know where to begin when talking compliance and what their website needs. They only know they need to be compliant. But if someone were to tell you they are looking for an “ADA-compliant” website, legislation from the pre-smartphone era won’t help you. What you truly need is an app that complies with the WCAG — so save yourself some dead-end search frustration and start there.

Follow the Guides Like a Developer

If you opened the WCAG and immediately felt intimidated or overwhelmed by the breadth of information, don’t be. First off, accessibility is not all-or-nothing. One small change to follow accessibility standards is worthwhile.

Creating accessible software (like creating software in general) is not the job of a developer alone. Some pieces such as legible font choice and touch-target sizes are the responsibility of the UI designer. Other pieces like heading structure and meaningful link text are the responsibility of a content strategist.

Just as you would not expect your designer to understand how to follow guidance for HTML tags, you are not expected to understand how to pick a color palate with appropriate contrast ratios. Understand that some techniques within the guidelines are for you to consume and apply — and others are not.

Making Code Accessible — For Your New Teammates

A lot of newbie accessibility sites say to start by downloading and using a screen reader to see what happens with your site, but I’m not advocating you do this. Rather than think of assistive technologies (screen readers, etc) as software you download, think of them as another developer on your team.

Treat assistive technology like another member of your development team

Assistive technologies are built to understand and interpret code (assuming the code is written well). Like leaving comments in code for other teammates to read, you need to leave markup in your code for assistive technology. Where? In your HTML since assistive technologies sit client-side and will read from the DOM.

Here are a few newbie-friendly accessibility tips to get started:

1. Add Meta to Everything: Any images or videos (called “non-text content”) should have an alt attribute to describe content. Anything with a state (such as a radio button that is checked/not checked or a tab that is active/inactive) should have an indication for the current state.
2. Use the Right Tag for the Job: To a piece of assistive technology, a <div> and a <section> have similar meaning, but a <div class=”button”> and a <button> tag have very different connotations — use the correct tags for each piece of functionality.
3. Respect the DOM Order: do not short-cut HTML by using CSS to make the page appear in a visually different order. Also, refrain from use of JavaScript to change the DOM order unless absolutely necessary. Since assistive technology relies on the DOM, the HTML order and visual order should be the same, and the HTML shouldn’t be disrupted by new elements popping in and out.

<h1>Bad Code</h1>
<p class="linktext" onclick="do_thing()">Click</p>
<div class="button" onclick="do_thing()">Click</div>
<h4>Not actually a title but I like the h4 formatting so I'm going to use it</h4>
<div class="container">
  <div style="position: absolute; right: 0px">Last</div>
  <div style="position: absolute; right: 100px">Middle</div>
  <div style="position: absolute; right: 200px">First</div>
</div>
<br>
<h1>Better Code</h1>
<a href="/newpage">Go To New Page</a>
<button>Submit a Form</button>
<p class="appropriate-style">I'm formatted like I should be</p>
<section class="container">
  <div>First</div>
  <div>Middle</div>
  <div>Last</div>
</section>

Yes, it truly is that easy to write usable code. If you take nothing else from this article, I want you to know that getting started with writing accessible code and spelling ‘accessible’ are on the same level of difficulty.

Single lines of accessible code can be written without doing a complete WCAG application overhaul. So, what are you waiting for? Javascript to make a DOM element appear?