Web Accessibility

#webdev #a11y #beginners #css

People have diverse abilities, skills, tools, preferences, and expectations that can impact how they use the Web.

I want to start by citing reference to stats I found via Sheri Byrne-Haber, a prominent inclusion leader and advocate for universal web accessibility.

Over 95% of the web is inaccessible to individuals who use assistive technologies and it takes approximately 8 seconds for them to make up their minds about whether they will continue or abandon that website or application.

Web accessibility means that websites, tools, and technologies are intentionally designed and developed so that people with disabilities can use them.

Creating accessible websites and apps reaches significantly more users.

We can better reach users who may have:

Permanent disabilities, such as visual, mobility, cognitive or auditory impairments
Temporary Disabilities, such as a user with a broken or sprained finger or temporary vision loss due to lost glasses or contacts
Situational Disabilities, where for example, a parent might be cooking with one hand, holding a a child in another arm while trying to place an order on a website. OR something as common as low screen visibility due to bright sunlight

Web Accessibility encompasses so much, I've included resources for more info at the end of this post. Because I can only scratch the surface here, I'll focus on 3 major accessibility considerations.

1. Perceivable Content

Provide Text Alternatives for Non-Text Content

Informative Images: For images that convey information or content, provide concise, descriptive alt text.

alt=”description of image”;

Complex Images: If an image is complex and cannot be fully described in a few words, consider providing longer descriptions through aria-describedby or linked descriptions.

<button aria-describedby="delete-desc">Add Friend</button>

<p id="delete-desc">  Items that are deleted will be permanently removed immediately. Deleted items can no longer be accessed after deletion. </p>

Both aria-labelledby and aria-describedby reference other elements to calculate a text alternative, but a label should be concise, while a description is intended to provide more verbose information; a label describes the essence of an object, while a description provides more information that the user might need.

The elements linked via aria-describedby don't need to be visible. It is possible to reference an element even if that element is hidden. For example, a form control can have a description that is hidden by default that is revealed on request using a disclosure widget like a "more information" icon. The sighted user clicks on the icon; for assistive technology users the description is referenced from that form field directly with aria-describedby.

Icons with Text Labels: Whenever possible, pair icons with text labels. This helps users with different types of disabilities understand the context. Also, generally use ARIA Labels: ARIA (which stands for Accessible Rich Internet Applications) labels to provide additional information about icons or graphics, if necessary.

// The aria-label attribute defines a string value that labels an interactive element.
<button aria-label="Open" onclick="modal.open()">

2. Operable User Interface

Keyboard Accessibility

Keyboard accessibility is a fundamental aspect of web accessibility. It ensures that people with mobility impairments, especially those who cannot use a mouse, can navigate and interact with a website using only keyboard inputs.

Good HTML Semantics
includes the proper use of nav, section, main, and heading tag hierarchy: h1 thru h6 tags. This allows for users to:
Skip Links:
skipping navigation links with a keydown of the 'tab' key at the beginning of the page allows users to jump directly to the main content or important sections, bypassing navigation menus.
Tab Order:
Arrange the tab order of elements in a logical sequence that mirrors the visual layout. Users should be able to navigate through content in a predictable and intuitive manner. Setting tab orders: tabindex="0" means that the element should be focusable in sequential keyboard navigation, after any positive tabindex values. The focus navigation order of these elements is defined by their order in the document source.

<!DOCTYPE html>
<html>
  <head>
    <title>Parcel Sandbox</title>
    <meta charset="UTF-8" />
  </head>

  <body>
    <div id="app"></div>
    <div class="overflow-hidden">
      <p>Click Here and start tabbing.</p>
      <label>First in tab order:<input type="text" /></label>
      <div tabindex="0">Tabbable due to tabindex 0.</div>
      <div>Not tabbable: no tabindex.</div>
      <label>Third in tab order:<input type="text" /></label>
      <div>Not tabbable: no tabindex AGAIN.</div>
      <div tabindex="0">Tabbable due to tabindex 0.</div>
      <div>Not tabbable: no tabindex AGAIN.</div>
      <div tabindex="-1">Not tabbable: due to tabindex -1 HERE.</div>
      <script src="./index.mjs" type="module"></script>
    </div>
  </body>
</html>

Focus indicators: Ensure that interactive elements, such as links, buttons, and form fields, have visible focus indicators when they are highlighted using the keyboard. focus-visible helps users understand where they are on the page and which element is currently selected.


input:focus-visible,
div:focus-visible {
  outline: 2px solid blueviolet;
  border-radius: 3px;
}

3. Testing Accessibility Features

Test the site or app with screen readers. Here's a great screen reader demo by Mark Sutton of UC San Francisco:
https://www.youtube.com/watch?v=dEbl5jvLKGQ
Test Type Colors v. Background Colors with a Contrast Checker: https://webaim.org/resources/contrastchecker/
Check the Accessibility of the website with an automated checker: https://wave.webaim.org/
User Testing and getting Feedback is ideal when launching any feature. Be sure to involve users with disabilities in testing. This is extremely important if we truly want to ensure user accessibility.
Keep Gathering feedback. Continue to make improvements and text compatibility with a variety of assistive technologies as these technologies evolve over time.

Thanks for reading and I truly hope this was helpful.

Resources

W3C: https://www.w3.org/WAI/fundamentals/accessibility-intro/
Quick reference: https://www.w3.org/WAI/WCAG21/quickref/
Contrast Checker: https://webaim.org/resources/contrastchecker/
WCAG 2: checklist & standards: https://webaim.org/standards/wcag/checklist
ADA.gov guidelines for web accessibility: https://www.ada.gov/resources/web-guidance/
UCSF screen reader demo: https://www.youtube.com/watch?v=dEbl5jvLKGQ
What do people with disabilities check when they first arrive on a website: https://www.youtube.com/watch?v=xYl2lAX-BTM

Top comments (6)

Mardeg • Aug 31 '23 • Edited

Thank you for this. I found it handy in Firefox to use the extension "Activate Reader View" to force webpages that Firefox's algorithm doesn't make the reader icon appear for. This shows how horribly inept many webpages are at accessibility, sometimes with hilarious results when you click the "Listen" button in that view to hear the page content read out loud.
One example of the webaim accessibility checker on a well-behaved page shows what you mentioned with being able to tab through substeps of a how-to guide. Semantic HTML with schema attributes in the source of that page is a good demonstration of never needing to use DIV elements.