The Understood front-end team has a special focus on removing barriers for people who learn and think differently. Our core users have ADHD, dyslexia, and other common challenges. But we are committed to creating products that meet the needs of all people. To do this, we combine accessibility and usability in ways that increase ease of use for everyone. This article outlines the why and how of our process. We also include basic steps on how to fix common accessibility issues.

Why Is Digital Accessibility Important?

Understood serves the one in five people who learn and think differently, which translates to approximately 70 million people in the U.S. alone. Learning and thinking differences can include the areas of memory, attention, and reading, as well as language and math, among others.

The Understood front-end team specializes in serving users who learn and think differently. But we are committed to creating products that meet the needs of all people.

Despite how common disabilities are, an article in AdWeek cited the fairly shocking fact that only 2% of all websites meet accessibility standards. Those guidelines are set out by the Web Content Accessibility Guidelines (WCAG), known and accepted worldwide as the minimum requirements to meet digital accessibility.

WCAGs are essential to our work, but they serve as a floor, not a ceiling. These standards should underlie each website and app but also be woven throughout the fabric of every developer’s process. Building and maintaining coding configurations that ensure error-free and equal access is the clarion call for all developers and designers.

Ethically, culturally, financially, and legally, expanding accessibility to include neurodivergent people and those with other disabilities is an intelligent and highly relevant business strategy.

Deep Focus On Accessibility

The engineering team at Understood.org is working to combine accessibility and usability in ways that improve ease of use for everyone.

We define accessibility as removing barriers for people to gain equal access to information, particularly neurodivergent people, and usability as making products like websites and apps easy to use for all people. That includes how simple the product is to use the first time and if the experience was gratifying, one that a user would likely repeat. A physical corollary would be knowing whether you need PUSH or PULL to open a door.

The reality is that digital accessibility is and will be an ongoing process.

Developers and designers who are fluent in accessibility are increasingly highly sought after. The Wall Street Journal noted job listings with ‘accessibility’ in the title grew a whopping 78% in 2021.

To be truly accessible, we need to implement solutions for people of all abilities, with both visible and invisible differences. Wheelchair ramps and closed captions are essential. But full access to the amazing power granted by access to goods, services, information, and communication options provided by the Internet also needs more learning and thinking support. This includes ways to help users focus and remember key points.

To do this, we have started putting people at the center of the process. Previously, the focus was on process, data evolution, key metrics, and results. That mindset leaves out a sizable portion of the population which diminishes access for users to all websites and apps across the board — from e-commerce and media outlets (including social and traditional) to government sites, search engines, and educational interests.

What Is The Role Of Front-End Developers

As developers, we play an important part in the consistency chain for coding best practices. We believe that due to timing and raising awareness, we are literally part of the process that is developing a foundational language for accessibility and usability that will be utilized by all future generations.

As such, we not only use our knowledge of programming languages to help develop the desired look and feel of our products, we ensure those products are accessible across multiple platforms.

And this is where the rubber meets the road: ensuring flawless operation when incorporating graphics, applications, audio, and video into the mix, ensuring those elements are cohesive and accessible for everyone by consistently testing for speed, usability, and accessibility.

Addressing Accessibility

We are on a continuous mission to ensure that sites are perceivable and error-free. Most industries come at the accessibility thing haphazardly. At Understood, we have found that the cleanest, most efficient way to approach it is to have Accessibility & Usability as prime factors in the initial development process.

It may seem like a basic statement, but as front-end developers, it is crucial that we have an in-depth understanding of how people actually use their devices when they are seeking information or online services.

At Understood, we reverse the traditional site creation process by listening closely to our users and accessibility consultants rather than designing first and asking questions second. It is not an exaggeration to say that our users’ insights guide our work.

The fundamentals of solid development and design practices apply doubly to accessibility and usability:

• Basic to advanced accessibility training for all technical teams, including front-end, backend, and designers.
• Attending accessibility conferences each year to keep up with the latest advancements and expand your knowledge base.
• Conducting surveys and tests with ‘actual’ instead of theoretical users. In our case, that would be people who learn and think differently.

Working As A Team

Every industry has its own style and uses a unique flow for development. Because serving people with learning and thinking differences is top-of-mind for us, Understood begins with User Research which includes creating and applying surveys. The information and insights we glean from those surveys inform the designers, who then share content and possibilities with product managers. That information gets relayed to the front-end team to update/create, and then the front-end team creates the site/product for designers who provide feedback and apply their edits.

Why does our process start with user research to inform designers? Deque Systems, a provider of compliance accessibility tools and software, observed that 67% of accessibility issues originate in the design phase of development.

Evolving and maintaining open and honest communications with product managers and design teams translates to less compliance and operational issues down the road. As with any team that works together yet asynchronously, it is sometimes easier to spot potential concerns from the other side. In our experience:

• Engineers detected accessibility flaws for which the designers found alternative solutions that also aligned with the design vision.
• Designers had top-flight guidance on crafting color contrast, character counts, and effective font styles.

All engineer tickets include accessibility, so each ticket includes an Accessibility Audit. That way, we assign time to deal with whatever issues were revealed.

In our process, we use screen readers to test our pages manually. If there is a video, we refine the closed captions and check individual elements, including headings, buttons, navigation, lists, and color contrast.

Our front-end team always works with product managers to prioritize tickets, and we make it a point to align both teams to make things work. Importantly, engineering teams are realistic when they spec out the appropriate timeline for creation and review.

Product managers then QA all the features and test for accessibility issues. This means that we have two entire teams that review all features for accessibility and errors.

In evolving the workflow, we’ve learned how important it is to allocate time in sprints to work on accessibility.

Example

For our mobile app:

• We examine everything page by page and log all errors into a central database.
• We then convert that content to Jira tickets, complete with descriptions, screenshots, and story points.
• If we work with a third party, and one of its tools is not accessible, we work with them to make it accessible.

The Developer’s POV

• Will non-screen reader users have a comparable experience to that of screen reader users?
• Can users focus on every interactivity in the right order?
• Does the HTML markup make sense?
• Are we conveying helpful semantic and stating information to screen readers? For example, we don’t want repeated information that isn’t necessary or bad image descriptions that don’t serve.
• Make sure dynamic (error message for form, confirmation of login) changes are transmitted to screen reader users.
• Are our features or components keyboard accessible?

The Designer’s POV

• Is there sufficient color contrast?
• Do we have a good font size, clean flow, and layout throughout?
• Does the light/dark mode function well and look good?
• Are all interactions reachable and executable?

Fixing Common Accessibility Errors

There’s a wide range of issues that can compromise accessibility, including those the website webaim.org calls “mistakes, misconceptions, over-indulgences, intricacies, and generally silly aspects of modern accessibility.” We find that webaim.org is an invaluable resource for understanding and then rectifying just about anything that can go haywire.

In the article for freecodecamp.org, Ilknur Eren, a front-end developer on our team, included a chart illustrating the most common types of WCAG 2 failures that WebAIM says comprise 96.8% of all accessibility errors:

WCAG Failure Type	% of home pages in 2022	% of home pages in 2021	% of home pages in 2020	% of home pages in 2019
Low contrast text	83.9%	86.4%	86.3%	85.3%
Missing alternative text for images	55.4%	60.6%	66.0%	68.0%
Empty links	50.1%	51.3%	59.9%	58.1%
Missing form input labels	46.1%	54.4%	53.8%	52.8%
Empty buttons	27.2%	26.9%	28.7%	25.0%
Missing document language	22.3%	28.9%	28.0%	33.1%

This chart lists the biggies, but read on for those that are most common and for understanding quick fixes.

Missing Alternative Text For Images

Understanding the “why” of a coding style is as important as knowing a specific guideline. For images, the context from image to image will vary and should determine the code because algorithms can’t always interpret the meaning of an image.

One classic example of this is creating alternative text for an image in the alt attribute of an <img> tag.

If you don’t understand why you’re doing it, you may create something that isn’t helpful to the end user but may actually create a brand new barrier.

Say we have an image, and we add the alt attribute:

<img src="example.png" alt="image"/>

While this might not get flagged by automated accessibility tests, a screen reader focusing on this image will say, “image, image.” It doesn’t inform the user and precludes their ability to solve their problem of understanding how to exit a program.

Low Contrast Text

According to recent reports from the WebAim Million, over the last three years, by far the most significant accessibility error is low contrast text. A surprising 80% of websites have this error, but it is relatively simple to fix. Google has a free tool called Lighthouse that makes it quick and easy to check the color contrast on any web page.

Missing Form Input Labels

According to WebAim, in 2021, half of the delinquent websites were missing their form input labels, which describe why the various fields in the form are for.

One of the most common missing labels is for search forms. If there is no label on a search form, screen readers won’t know what the form is.

Here’s how you fix that in HTML:

<label for="searchLabel" class="sr-only">Search</label>
<input type="text" name="search" id="searchLabel>
<input type="submit" value="Search">

And here’s CSS coding for the screen-reader portion of that HTML snippet:

.sr-only{
  position:absolute;
  left:-10000px;
  top:auto;
  width:1px;
  height:1px;
  overflow:hidden;
}

Empty Links

As above, almost half of the websites had empty links. This is a simple issue to identify and resolve.

For example, a Facebook logo that doesn’t add a label for a screen reader user will generate an empty link accessibility issue for a non-sighted user.

Adding a label to a link is simple and straightforward:

<a href="/facebook-page">
  <i aria-hidden="true"></i>
  <span class="sr-only">Facebook</span>
</a>

.sr-only{
  position:absolute;
  left:-10000px;
  top:auto;
  width:1px;
  height:1px;
  overflow:hidden;
}

Missing Document Language

It’s essential to list the language of the page. Screen readers use document language to decide how to pronounce words.

That said, somewhere between 28% and 33% of homepages have been missing a document language for the previous three years.

Add the language to the HTML tag:

<html lang="en">
...
</html>

Empty Buttons

It can be frustrating to click on a button and have nothing happen. The user is trying to submit a form or show/hide elements, and the lack of functionality is enough to make them exit the page.

Like empty links, buttons need text for screen readers to read when on focus.

If an image is used inside a button, we should add an alt attribute to create a functional image:

<button type="submit">
  <img src="/search.svg" alt="Search" />
</button>

Key Takeaways

In this day and age, accessibility should not be an afterthought. Everybody has the right to access the benefits and power of the Internet and apps that make daily life easier and more enjoyable.

When reviewing sites and apps for usability, make sure to test your products manually for accessibility. It makes a difference. Allocate specific time to focus on accessibility and maintain open communication channels with product managers and designers.

Continuing to explore technical training and new knowledge goes hand in hand with interviewing and surveying people who think differently so that what you produce and put out into the world is of the highest quality and easy for everyone to use.