unicorn-utterances/content/blog/intro-to-web-accessability/article.md

title, description, published, authors, tags, attached, license, originalLink

title	description	published	authors	tags	attached	license	originalLink
Introduction to Web Accessibility (A11Y)		2021-05-30T22:12:03.284Z	crutchcorn	a11y javascript web		coderpad	https://coderpad.io/blog/rust-enums-matching-options-api/

Friendly Foundations

If you're coming across this article and haven't heard about "accessibility" (often shortened to "A11Y") before, that's okay. We're all learning at different speeds and come across new things all the time. That said, accessibility is a critical component to any frontend engineer's responsibilities. We implore you to explore what that means, not just in this blog post but beyond with your teams and communities.

First, let's define what "accessibility" is. Accessibility in engineering is "the process of creating products that are usable by people with the widest possible range of abilities".

Your may have vision-impaired or blind users of your app. These users may rely on screen readers, which allows users to navigate their computer with their sense of hearing. These methods may be used in tandem with the visual experience for some users or used independently to navigate their computer auditorily.

You may also have have users with limited mobility, who utilizes buttons to trigger different behaviors on their machine.

If you're a visual learner who would like to see some short-and-quick workflows from users like this, one of Apple's ads displays a few uses cases that proper accessibility support can enable.

Something to keep in mind is that these disabilities may not be permanent. For example, if you fall and break your arm, you may be only using one arm while healing. Likewise, there's situational impairments as well. A new parent may have to hold their child while trying to do things. Here's a chart that outlines a few more of these examples:

	Permanent	Temporary	Situational
Touch	One arm	Arm injury	New parent
See	Blind	Cataract	Distracted driver
Hear	Deaf	Ear infection	Bartender
Speak	Non-verbal	Laryngitis	Heavy accent

This chart was originally created by Microsoft as part of their Inclusive Toolkit manual

Creating an application that's accessible means that you're making a better experience for all of your users, ready for any context they might be using your app in.

In addition to the moral and financial incentives (by opening the door to more users), many organizations have a legal requirement to meet accessibility. US government software is subject to Section 508, which requires compliance to the WCAG guidelines (which we'll touch on later). Likewise, private US companies may be subject to compliance due to the "Americans with Disabilities Act" (shortened to "ADA"). The U.S. isn't the only country with these requirements, either. According to WCAG's reference page for various legal laws, there are at least 40 such laws in place around the world.

Please note that we are not giving legal advice. This is simply meant for educational purposes for individuals. Consult legal authorities for the appropriate jurisdiction

Accessibility isn't a pure science, however. If you're sighted, this may be an abstract idea at first. However, think of it like this: the colors an app uses or a button's placement visually may convey different messages and meaning depending on their context. This same problem applies to users of screen-readers and other accessible tech as well, just with different constraints. Having the screen visually cluttered, making content difficult to read, might be a similar experience to having a site where the footer's contents are inexplicably read before the main page's content.

Sensible Standards

While accessibility has some levels of subjectivity involved, it's important to note that there are standards surrounding web application's accessibility support. "Web Content Accessibility Guidelines" (shortened to "WCAG") are guidelines to follow when considering your app's accessibility. These guidelines are published by a subgroup of the World Wide Web Consortium (shortened to "W3C"). W3C is the main international standards organization for the Internet. WCAG acts as the de-facto guidelines for A11Y.

There are different scales of accessibility as well. WCAG includes three different levels of conformance:

• Level A is the minimum level.
• Level AA includes all Level A and AA requirements. Many organizations strive to meet Level AA.
• Level AAA includes all Level A, AA, and AAA requirements.

Meeting AA requirements is typically seen as a good commitment to accessibility, but AAA will open more doors to your users and is the gold-standard for accessible UX.

Far from a comprehensive list, AA covers things like:

• Screen reader experience
• Minimum contrast guidelines
• Text resize support
• Video captions
• Basic support for keyboard navigation

Meanwhile, AAA includes support for:

• High contrast mode
• Reduced/restricted animations
• Video sign language support
• Full website functionality with keyboard

Among other things.

Smartly using Semantic HTML Tags

One of the easiest things you can do for your application's accessibility is to use semantic HTML tags.

Let's say we have HTML to display fruits in a list:

<div>
    <div>Orange</div>
    <div>Banana</div>
    <div>Grapefruit</div>
</div>

While this will display the contents, and you may be able to use CSS to add styling to make this look like a list, the browser has no way of knowing that this is a list. This is reflected in how screen-readers read that HTML output.

--------- ADD VIDEO OF VOICEOVER READING THIS HTML ----------

Likewise, search engine crawlers won't know that this is a list. If you're only using div tags as far as Google's concerned, you have no lists, no headings, nothing. This makes the page significantly less engaging and therefore rank more poorly.

Let's compare that to using the correct HTML tags for a list.

<ul aria-label="List of fruits">
    <li>Orange</li>
    <li>Banana</li>
    <li>Grapefruit</li>
</ul>

--------- ADD VIDEO OF VOICEOVER READING THIS HTML ----------

As you can hear, this screen-reader is now able to read out that it's a list. It makes navigation of that list easier for those users by allowing them to quickly skip to the next list item and hear the index of an item in the list.

Not only will this enhance the experience of your screen-reader using users, but because search engine crawlers rely on HTML tags to inform what's what, your site will rank better in search engine queries as well! This is a massive boon to your site's SEO score.

Understand aria- properties

In our previous example, we used an HTML attribute aria-label on our ul. ARIA is collection of HTML attributes that allow you to enhance the accessibility in applications. That said, it is highly encouraged to use the suggested HTML tags instead of aria attributes whenever possible. Think of aria as a complex low level API that can enhance your experience when done properly, but drastically harm user experience when unproperly utilized.

A small subsection of aria- attributes includes:

• aria-labelledby - Associate the element with another element's text as the label
• aria-expanded - A Boolean value meant to communicate when a dropdown is expanded
• aria-valuemin - The minimum allowed value in a numerical input
• aria-valuemax - The maximum allowed value of a numerical input

Additional to aria props, there's the role property that acts to have the browser see and read an element as a different one. Again, this is a highly advanced (and often incorrectly deployed) API for complex apps. To learn more, read through Mozilla's ARIA basics article.

Contrast is Cool

While screen-readers are imperative to consider for front-end work, a site's visuals can help provide a good experience for many users. While a certain color palette may be aesthetically pleasing, it may be difficult to read for a colorblind user. Colorblind users aren't the only ones impacted, however.

While there are various reasons a user might not be able to see weakly contrasted color, everyone is different. See if you can distinguish the text from the background in the displayed image with poor contrast:

Now, compare that to highly contrasted colors:

The contents are not only easier to distinguish from the background, but even for those that can see the contents it's made easier to focus on as a result of the increased contrast.

This said, not all contrasts are the same. Per WCAG guidelines, you may have a different ratio of contrast for different compliance levels. These contrast ratios depend on both font size as well as compliance level.

In this example you can see that the text passes the WCAG AA requirements for large text, but fails the same requirements for small text.

Fantastic Fonts

One of the most widely used accessibility features is font scaling. While many browsers default to a font size of 16px, the user is actually able to change settings on their device to configure websites to use a larger font size.

Many phones using iOS and Android allow users to change the font size on their mobile device. This feature so commonplace, that it often prompts users to change this setting when the phone is being set up.

iOS font size settings screen

Android font size settings screen

Not only do you have these settings on mobile devices, but they're available on desktop as well.

Using Chrome, go to your settings page, and you should be able to set your font size.

You can do the same in Firefox in your preferences.

Implementation

While browsers have the ability to set the font size, if you're using px, vw, vh, or other unit values for your fonts, the browser will not update these font sizes for you. In order to have your application rescale the font size to match the browser settings, you'll need to use the rem unit.

You can think of rem as a multiplier to apply to the default font size. When the browser's font size is set to 16px:

• 1rem will be 16px (1 * 16px)
• 1.5rem will be 24px (1.5 * 16px)
• 3rem will be 48px (3 * 16px)

Likewise, when the browser's font size is set to 20px:

• 1rem will be 20px (1 * 20px)
• 1.5rem will be 30px (1.5 * 20px)
• 3rem will be 60px (3 * 20px)

Something to keep in mind is that rem is a relative font size. It's relative to the root element's font size. This means that you cannot set a default px value font size in :root , as it will disable font scaling, even if the rest of your page is using rem values.

It's highly encouraged to keep font sizes standardized around the 1rem value. While this may seem like a frustrating limitation at first, see it from the user's perspective.

Say site "A" sets their font size to 1rem and site "B" sets their font size to 0.8rem. When the user switches from "A" to "B", to font drastically decreases, requiring the user to change their font size. Then, when they switch back to site "A", they're left with too large of a font size. By respecting the user's setting of font size, you're ensuring that their experience jumping from site-to-site is more consistent and a nicer experience.

Want to learn more about rem and font sizing? Take a look at this in-depth blog post that covers even more.

Keyboard is King

While the average of users might utilize your application with a mouse

This impacts not only people that are using screen readers on your site, but enables power users of your application to be more efficient as well.

https://www.w3.org/TR/WCAG21/#keyboard-no-exception

Humans Can’t Be Automated

The perception for some is that accessibility is something that can be 1:1 adapted from an existing design. This is often untrue. You may want to add a "Skip to contents" button that only shows up with tabbing for some sites, while the visual order and tab order might need to be flipped for a better experience for screen-reader users. Remember, accessibility is a form of user experience that has to be crafted by hand. Each decision has nuance to it and there are rarely objectives of which experience is better than others. Because of this, many companies will have dedicated accessibility specialists alongside their design and engineering teams.

You also need to make sure to test your application as you would any other part of your app. We'll touch on this more in a future section.

If anyone is ever advertising to you that your project can be made accessible without any changes to your codebase: they're either lying to you or don't understand accessibility properly.

Assistance is Amicable

While full automation will never be possible for improving a project's accessibility, not everyone proposing assistance in the process is trying to sell snake-oil.

For example, Deque's open source Axe project can help identify issues such as common HTML semantic errors, contrast problems, and more. There are even libraries that help integrate Axe into your project's linters such as one for React called eslint-plugin-jsx-a11y.

Keep in mind, however, that these tools are not infallible and are meant to supplement accessibility experts working with your engineering team, not replace them.

Test, Test, Test Again

Testing is a critical component to any application release. Whether using automated testing solutions or QA teams, they help ensure that your users are getting the best experience possible without regressions in an application's behavior.

As a developer working on the frontend, you should be regularly turning on a screen-reader to analyze your site and navigating your application with only your keyboard. This will help enforce the feedback loop between building the functionality and getting it shipped to users. Make it part of your PR review process - have other members of your team test with a screen-reader as they would visually analyze new features.

You're also able to include automated tests that will help with A11Y regressions. Either using integration tests or e2e tests, you can use real-world behavior such as "search for an element with this label" or "tab over to this button" to ensure your application is functioning as-intended.

As mentioned in a previous section, the process to make your app accessible cannot be fully automated. This extends to testing as well. While real-world automated tests are fine and well, you need someone to experience the application on a broader scale to make sure the experience is as fluid as it can be. While a specific component might be accessible by default, perhaps in specific usages it falls flat.

Fantastic Features

While there is plenty you can do to make existing functionality accessibility friendly, it's often forgotten that a strongly accessible app may opt to add specific functionality for it's users with disabilities.

Some great examples of things like this are sites with lots of user-generated content. For example, Twitter allows its users to add "alt" text to their uploaded images and GIFs. Likewise, YouTube has the ability to add subtitles and captions to uploaded videos on their platform.

Conclusion

We hope you've enjoyed learning from our accolade-worthy alliterative headlines.

While this article outlines many basics of web accessibility, it's far from a complete guide. Remember that accessibility is as much UX as visual design. To get it in a great place for your users takes active effort like any other part of your app.