A First-timer’s Guide to the Accessibility Galaxy
Before starting at Tamman my idea of accessible technology was extremely limited. My first assumptions were based on how users physically interacted with devices and not necessarily how they interacted with the content within those devices. While there have been various innovations which allow those with physical use constraints to interact with computers and game consoles with ease, these devices only address one side of the issue. Unbeknownst to me then, it was cemented into my brain that: 1.) disabilities are things that can always be seen, and 2.) that the main difficulty in the space is getting users to be able to physically interact with the devices and not necessarily what happens after that.
It’s no secret that most things that we use in our world aren’t designed with disabled users in mind. Even when they are, sometimes it can feel like more of an afterthought than a well formulated solution. On one hand, I get it. Making stuff is expensive, and putting extra consideration and money into features for a very limited group just doesn’t seem worth it to some people. On the other hand, I’ve come to believe Tamman’s ethos that information is a human right and I believe it’s both morally and ethically (and legally depending on where you live) wrong to be unable to access information that otherwise would be freely obtainable. With this in mind, the Americans with Disabilities Act of 1990 (ADA) was a landmark piece of civil rights legislation that prohibited discrimination based on disability. It stipulated and mandated various accommodations to allow disabled people access to buildings, employment, and opportunities as those without use constraints. At the time of writing, the Internet was still in its infancy and the text failed to mention anything about it. As time progressed it became more and more apparent that the Internet was a utility that needed similar mandates and guidelines.
Nowadays it’s unheard of if a business or other entity doesn’t have a digital presence like a website or Facebook page. In fact, many services are being ported to the internet to allow customers to interact with or place orders from the comfort of their phone or computer. While on the surface this seems like a great idea, it becomes an issue when your online service is impossible to navigate for users with various use constraints. When this is the case, not only can you get in legal trouble over this issue, the implications of alienating a portion of your customer or user base has far greater consequences. As a creator, I believe you ought to have the responsibility to make sure that as many people as possible can access what you make no matter their ability or situation. Not only do accessible websites allow for this, they also tend to have better SEO, better overall usability, reach more people, load quicker, and encourage good coding practices, among other things. As the saying goes, necessary for some, but good for all.
At this point, I know what you’re thinking. “All of this sounds great! I get to address digital issues that had previously limited groups of people AND make a great product? Where do I start?”. Like you, I found myself in a similar situation. When I first started at Tamman, the most accessibility work I’ve done up to that point consisted mainly of automated evaluation tools (Google Lighthouse, WAVE) and general no-brainers picked up from learning the trade. At the time, I was also dipping my toes into various UX and UI design philosophies to aid in creating intuitive and functional interfaces. The idea I had in my head of accessibility was much different than the actual work being done here at Tamman, which in simple terms is much wider in scope with very granular solutions to each problem.
HTML Elements & ARIA
The first big thing I discovered was the myriad of native HTML elements whose sole purpose is to aid in an accessible browsing experience for the end user. Examples of this include but are not limited to: article, aside, details, figcaption, figure, footer, header, main, mark, nav, section, summary, and time. Initially, I saw little incentive in using these elements because they didn’t display (or present) any differently on the page than a regular old div. Little did I know, these elements have the important job of providing much needed semantic value to a website. While assisting screen readers in navigating the page, semantic elements also influence a page’s search rankings and make code more readable for the developers themselves. Instead of using a bunch of div tags to make everything on the page, these built in semantic elements allow for a more consistent and coherent HTML foundation to build on.
If the goal is an accessible browsing experience, using semantic markup by itself isn’t going to be enough. Luckily, HTML provides some more built in tools to fine tune the accessible experience, the most powerful being ARIA and its associated roles and states. ARIA stands for Accessible Rich Internet Applications, and encompasses many different semantic uses through the browser’s accessibility API. The role attribute can be added to an HTML element to specify its type and expected behavior to assistive technology. For example, if you made a custom button using a div, you can add role=’button’ to define this element as an interactive button to a screen reader that would otherwise announce it in a more ambiguous manner. Similar roles exist for elements such as switches, sliders, tabs, checkboxes, lists, tables, alerts, and many others. Used in conjunction with roles, ARIA states add another layer of granularity to accessible elements by allowing them to have certain values that correspond to various functionalities they’re associated with. Continuing the previous example, let’s say we want to allow our custom button to be toggled. We would add aria-pressed={isButtonPressed} where isButtonPressed is a boolean corresponding to whether or not the button is toggled on or off. Keep in mind that ARIA does not change how the element looks or works on the page, it is solely to inform assistive tech like screen readers about the status of various things on the page. If someone were to navigate to our button, the screen reader would announce that they were on a button element and that it is currently “pressed”, indicating that it can be toggled on and off. Combining the role and aria-* attributes can provide near limitless possibilities (and therefore zero excuses) for accessible components and experiences.
Another commonly overlooked but critical practice is the structure and hierarchy of heading elements on the page. When I was inexperienced, I would primarily use the various headings depending on how big I wanted my text to be, which I now know to be a classic rookie mistake. The main function of headings is to construct an easily navigable page flow that increases in specificity as it’s traversed. In simpler terms, a page should always start with an h1 and decrease in level with each specific or unique sub-component. This structure is useful to not only screen readers and other assistive technology, but also things like user agents and web crawlers. Search engines like Google rely on heading data (among other things) to construct a table of contents for a web page that can be easily categorized and searched later on. When it comes to h1’s, there should only be one per page view to identify the overall purpose or title of the content. Headings should be numbered to organize the content on the page. You can nest headings to denote subsections, but do not skip heading levels. People using assistive technology to read the content aloud will lose context looking for a “missing” heading.
Images
An extremely large part of the internet that most people take for granted are images. As a person with uninhibited eyesight (save for glasses), images are core enhancements that can be used in a multitude of ways from conveying an emotion to a diagram explaining a complex task. Without the visual element that images and pictures provide, visually impaired users could be having an entirely different experience than what the creators originally intended. Given the sheer amount of information that images can convey as well as their importance to page content, it can be difficult to provide a solution that provides the context and content of the original in an accessible way. A separate experience is not really an equal one, but unfortunately we’re sometimes limited by the technology at our disposal. There is no single catch-all way to make an image accessible as it depends on the context which the image lives in. Most images that convey something in terms of context must be given alt-text which stands for alternative text. Alt-text is background information for a screenreader that provides a short description of the image.
Images that are minimally decorative like icons are the primary use case for this as we want to avoid removing content as much as possible. The easiest and least involved technique when the image is not vital to the subject matter is to just hide the image from the screen reader so the user will never encounter it. Implementation can be done two ways: aria-hidden='true‘ or role='presentation'. Both of these attributes accomplish similar goals but work differently under the hood. The presentation role removes all semantic information about the element, essentially stripping it of its identity but still keeping it in the accessibility tree. In the case of images, there isn’t much of a backup identification so they ultimately get ignored by the screen reader. Similarly, aria-hidden='true‘ also makes the element invisible to the screen reader but in a more assertive way by completely removing itself from the accessibility tree altogether.
There might be situations where an image contains substantial information such as a diagram or chart that can’t be conveyed in a short alt text. There are a multitude of solutions for a problem like this but they all have the same core philosophy of displaying a longer description somewhere else that is linked back to the image. One of these includes the figure and figcaption elements. The implementation is pretty simple, all you need to do is wrap the image in a figure tag and include the figcaption inside it with some sort of caption or description. Another valuable tool is the aria-details attribute. This attribute takes an id of the element that contains a more detailed description or additional information that relates to the current element. Assistive technologies inform the user of the extra info and allows them to navigate to it if needed. For more complex interactive experiences that also involve informationally dense images, the solution really depends on how the content gets displayed. A custom implementation using some combination of the above with aria-live and a specific role should work in most cases.
Tab order and focus states play important but often overlooked roles in accessible design. When navigating a website using the keyboard, the tab key is commonly used to cycle through interactive elements on the page with the focus state providing an indicator of the current selection. This is a common use case for someone who could be physically impaired but not necessarily visually impaired. All browsers have their own focus state by default, but if you want your site to have a consistent look and feel it’s a good idea to implement your own focus style. This is commonly accomplished by adding an outline or box-shadow with a :focus CSS selector to the element. Along with the focus state, having a logical tab order prevents confusion and allows for more unambiguous keyboard navigation. Tab order is the order in which the user can move the focus through each interactive element on the page. A keyboard user tabbing through the page should be able to focus various elements in the order that they appear on the screen. If the focus shifts wildly throughout the page in no particular order, it can be extremely confusing and difficult for a keyboard user to continue on the site. Because tab order depends on the order that the elements appear in the DOM, simply structuring your HTML in a readable and rational manner is all that’s needed.
One of the more frustrating aspects of catering to assistive technology is the lack of consistent behavior among screen readers. Much like web browsers, all screen readers follow the same general principles when it comes to converting visual information to speech, but each have slightly different ways of accomplishing this. Apple’s Voiceover for example, may announce the text inside of an element twice whereas NVDA or JAWS might not say the text at all. A screen reader could announce a clickable region as a “group” on one browser and as a “region” on another when all you want is for it to be called a button. Factoring the various browsers and their own idiosyncrasies just adds another layer of irritation on top of this issue. Sometimes it feels like you’re wrangling 8 different kids at once to behave in public and it’s just not going too well. As annoying as it may be, understand that with time and experience you’ll be able to recognize and remediate these kinds of issues before they happen.
After drinking from the accessibility fire hose, it’s easy to get caught up in all of the flashy technical solutions and forget some of the common sense stuff. A large part of accessible design starts at the, (you guessed it) design stage way before the first lines of code are even written. Interacting with a website should be a fluid and natural process unimpeded by a confusing or misleading interface. The good news is, setting an accessible foundation is extremely easy but also tremendously effective at providing a solid base from the beginning. You can style a link or a button to match your branding, but don’t go out of your way to impede the standard understanding of how those interactive elements work in other websites.
After reading all of the above, it’s easy to feel overwhelmed when starting to learn the ins and outs of the accessibility world. Fortunately there is a sprawling online community dedicated to just this subject with a multitude of free resources to help new people with the ropes. Some of the best ones include W3, WebAIM, Mozilla Developer Network, and The A11Y Project. Along with these big names, there are thousands of StackOverflow questions, blog posts, forum threads, Medium articles, YouTube videos, A11y Slack, and even tweets (accessibility Twitter is a thing) that can probably answer a lot of the questions you might have when first starting out. As accessibility and accessible design become more mainstream, expect these kinds of resources to multiply exponentially. Some of this stuff is going to be challenging, just like trying to solve any other problem. At the end of the day, by entering into this space, you’re investing time and energy into technology and design that you believe will make the world a better place. Making a difference no matter how small or large could be minuscule for you, but to someone else it could ultimately make or break the way they live their life. That difference is what got me into engineering and tech in the first place, and I believe that drive is what spurs innovation for a better quality of life overall. Welcome to the accessibility universe!
Devon Pirestani is a front-end developer at Tamman
Up Next
Thoughts
I just want to work: A perspective for employees with disabilities
