Accessibility has been experiencing increased visibility and adoption in recent years, mandated both by governmental regulations and end-users’ needs. As with any other quality attribute, it is ideal for accessibility to be incorporated in the early stages of design and engineering, but organizations that didn’t initially take accessibility into account can still address it now—it’s better late than never.
So, how can everyone be encouraged to develop an awareness and appreciation of accessibility?
At the onset, accessibility is a top-down process in most organizations. The investment has to come from stakeholders, starting with executives, who often will first need to be educated on what accessibility is and why it is important. If training sessions will have to be done to educate the team and stakeholders on accessibility, it is certainly a worthwhile investment.
Although early adoption is recommended, I understand that many organizations traditionally have focused on feature sets and core functionality while attributes such as accessibility have taken a back seat. As organizations work on determining how they fare on accessibility, what their goals are, and what gaps need to be fixed, the message to drive home is that it is okay if accessibility is an afterthought—this time.
The goals here are to make your existing sites and apps as accessible as possible now, after the fact, but to plan for accessibility early on going forward. Here are the main attributes you should consider from the design, development, and testing angles.
Planning for Accessibility from the Beginning
One good thing about accessibility is the overall ease with which it can be understood. The World Wide Web Consortium (W3C), with its Web Accessibility Initiative and Web Content Accessibility Guidelines (WCAG), is an excellent resource for handy practical examples and core guidelines, as well as explanations for what accessibility means and why it is important.
When designing for accessibility, the basics you need to take into account are that your site or app adheres to the most recent WCAG guidelines; it covers a cross-section of disabilities, including visual, auditory, cognitive, and motor skill-related issues; and it incorporates the critical set that is implementable by engineers who are not specialized in accessibility testing.
The nature of accessibility means testing for it will require tools, including assistive tools, such as screen readers and magnifiers, and automated tools, such as browser add-ons and color analyzers. But these tools are also fairly easy to gain an initial understanding of. Likewise, static code reviews revolve around straightforward parameters such as perceivability, operability, understandability, and robustness.
A client recently asked my company for an example of a site we recommend for good accessibility design and engineering practices. In our experience of having tested several applications for accessibility and based on feedback from our sighted and nonsighted engineers, we suggested the BBC website to be one such good reference. Try comparing the BBC site against the checklist I provide below to establish a good understanding of how the elements of accessibility can be implemented well.
This is just a handy checklist to promote accessible design. When considering accessibility in your site or app, keep these points in mind:
- Meaningful alt text: Include appropriate, equivalent alternative text for all images
- Purpose of links: Determine the purpose from the link text. This also applies to forms, images, buttons, and image map hotspots
- Keyboard accessibility: All page functionality should be accessible via keyboard
- Focus order: Navigation, order of links, and form elements must all be logically correct
- Use of color: Color can’t be the only way to communicate information
- Bypass blocks: Ensure direct access to the webpage’s primary content
- Semantic markup: Indicate a heading structure, list, block quote, etc.
This is a simple yet powerful checklist for accessibility that every engineer could easily include in their testing efforts, without the need for any complex tools. A handy set of shortcut and hot keys is all that is required.
I have saved the most important accessibility recommendation for last: Every engineer should be encouraged to develop end-user empathy. Developers and testers should do their best to understand who the end-users are, profile them, and study their personas and application usage patterns. These efforts go a long way toward appreciating the need for usability and accessibility.
Retrofitting Existing Sites for Accessibility Now
It can be quite an undertaking to bring an entire organization up to speed on core accessibility elements. But once the organization has made a commitment toward an inclusive design, getting the team on-boarded is completely feasible.
For example, in our organization, one thing we have done in the last year is make everyone aware of accessibility, keeping in mind the core elements to focus on as they interact with any product. This could be at the design stage, development stage, test stage, live environment, or even looking at a competitor’s product, as that can give a lot of insight into how your own product fares.
The good thing about accessibility is that defect fixes post-development are fairly feasible, unlike in certain other test areas where it may be very expensive if not impossible.
The information and checklist above are still the best starting point. Often, these fixes can be made in the code base. For instance, including alternative text is just a matter of add-on tags.
However, certain areas, such as adaptability and compatibility, are more complex to fix. This includes meaningful sequence in the product workflow (focusing on the sequence of the display of elements to enhance intuitiveness), information and relationships among various page elements (for example, if a page contains a table, the screen reader should read its elements in the right sequence), and use of sensory characteristics (for example, some content on the page may be defined only by shape, size, color, or orientation of objects, which is not a good practice).
These fixes may sometimes even involve making changes to the architecture of the product. In cases such as these, the team always has the extreme option of maintaining a parallel version of the application purely for accessibility. This is not a recommended option, as it causes maintenance efforts to surge, but if that is the most feasible option at the moment, it’s preferable to remaining completely inaccessible.
And even the most popular sites are not immune to accessibility issues. You might be surprised at how twenty leading American e-commerce sites fare on accessibility—for some, even basic elements such as alternate text are missing. Now, these issues are not rocket science to fix, but you have to know that they’re happening. The first step is to acknowledge these gaps and the need to fix them.
Start Your Accessibility Efforts Today
The industry’s product backlog in the space of accessibility today is huge—most applications are either inaccessible or hardly accessible. It is welcoming to see the awareness of and commitment to accessibility gradually increase at all levels.
Luckily, it’s easy to reverse-engineer accessibilty into your existing products. It is still okay for it to be an afterthought at this time, but the same may not be acceptable a few years down the line, so now is the time to play catch-up. Helping all your employees build basic accessibility appreciation and know-how is the first step. Making accessibility everyone’s responsibility is the best way to embrace it and bring it into the mainstream product engineering scope.
