Easy Accessibility Fixes

December 05, 2023
article featured image
An incredibly talented friend of mine is fully blind and managed to trudge through and finish law school, but still encounters an unacceptable number of inaccessible tools and services. Products are still made today without the simplest regards for disabled persons. We should comply with Section 508 because everyone should have equal access. And because it is good karma.

Table of Contents


    Accessibility shouldn't be an afterthought. Even if your company is a start-up, at some point during a potential aquisition, questions may arise on how long it will take to get your products into compliance. If you haven't started thinking about accessiblity yet, things could get expensive. Luckily, if your designers and developers keep an eye out for some common pitfalls, you can avoid some serious tech debt.

    §  Properly account for Title and Header

    It's very easy to overlook the layout of your web app. How is this presented to a screenreader? Is the document laid out in a way that makes sense?

    A screenreader will easily get tripped up over an non-descriptive XML file. To ensure your file has the necessary properties, open your SVG file and look at the start of the file. At the beginning of your file, add an attribute to <svg> called "aria-labelledby". Declare its value as "title". Just after your <svg\> tag, include an element called <title>, and insert the name of your site.

    <svg aria-labelledby="title" role="img" viewBox="0 0 726 514" version="1.1" 
    xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" >
    <title id="title" lang="en">James Hernandez — Senior User Experience Designer 
    and Front-end Developer</title>
     

    Nice! For good measure, make sure you wrap the entire thing in an h1 tag so accessibiilty tools know it's the primary header.

    <h1 className="p-0 m-0 d-flex align-items-center">
       [...]
    </h1>

    Other resources: SVG & Icon Fonts

    §  Mobile Menus

    Accessible Rich Internet Applications (ARIA) are used to enhance accessibility with websites. This is certainly not meant to replace native HTML semantics and behavior for assistive tech. It just never hurts to use both.

    Mobile menus could be enhanced with some ARIA properties. For the menu item itself, I like to use aria-expanded and have it toggle true or false based on its status. I aslo use aria-controls to let the browser know what element is controlled by it, which in this case is labeled as 'mobileMenu' by its id. I can also use aria-haspopup to let the user know there's an element appearing or disappearing based on its status.

    Aside from ARIA, you're menu toggle should be a button so that it will toggle on and off when a user clicks on their spacebar.

      <button
        type="button"
        className={
          'hamburger hamburger--spin ' + (isActive ? 'is-active' : null)
        }
        onClick={handleToggle}
        aria-label="Show Navigation Menu"
        tabIndex={0}
        id="menubutton"
        aria-expanded={isActive ? true : false}
        aria-controls="mobileMenu"
        aria-haspopup="true"
      >
        <div className="adNavHam hamburger-box">
          <div className="hamburger-inner"></div>
        </div>
      </button>
      <ul
        className={
          'adNavDrop position-absolute list-unstyled user-select-none ' +
          (isActive ? 'adNavDrop--show' : null)
        }
        id="mobileMenu"
        role="menu"
        aria-labelledby="menubutton"
        aria-label="website menu"
      >
        {items.map((item) => {
          const id = 'id' + Math.random().toString(16).slice(2); // unique identifier
          const { menuItem, url } = item;
          return (
            <li key={id} role="presentation">
              <a
                className="d-block"
                href={url}
                role="menuitem"
                onClick={() => handleMenuItemClick(url)}
              >
                {menuItem}
              </a>
            </li>
          );
        })}
      </ul>

    Properly marked navigation is critical. You remembered to wrap your main navigation with nav. But did you remember your navigation at the bottom? Did you also wrap this for your Previous and Next button or anything that directs the user through the app?

    • Every navigating element should be wrapped with a nav tag. Lists and nested lists should be used for intricate site layouts.

    Are you making sure elements that are invisible to sighted users are not being caught by screenreaders?

    In this case, we have a list item that's part of a navigation. If the page is the first of many, we don't want the Previous button to show. We don't want it to show up in the DOM inadvertently and cause confusion. A javascript ternary is demonstrated below hiding the wrapping <li> so it does not get improperly read.

    <li
      aria-hidden={isFirst ? 'true' : 'false'}
      className="paginationNav__section smallWidth">
      {!isFirst && (
        <PaginationButton
          href={prevPage}
          buttonContent="Previous"
          buttonPosition="left"
          buttonSize="small"
        />
      )}
    </li>