Basic accessibility features you should ALWAYS implement
Tags: programming, html, a11y
Published: 2021-11-15 20:46:07

Accessibility on the web has always been important, but it's only been in the last <10 years that a true emphasis on it has come about. Legally, it's against the law to build a site or application that doesn't adhere to the [Web Content Accessibility Guidelines](https://www.w3.org/TR/WCAG20/).

Purple Cow Agency has [this great article](https://purplecowagency.com/is-website-accessibility-a-legal-requirement/) where they answer some of the questions around accessibility. They do a great job of answering those questions and giving an easier-to-digest version of WCAG 2.1

> According to Title III of the Americans with Disabilities Act (ADA), all public areas must accommodate people with disabilities—this includes your website. Though the ADA doesn’t mention websites anywhere, the US courts interpret “places of public accommodation” to include the public domain of the internet.

Today, we're going to look at 3 commonly overlooked accessibility patterns you can add to your projects to get them a few steps closer to be fully accessible compliant!


## Accessible Modals
Modals are a very common design pattern across the web today. You see them for newsletter signups, requests for cookie tracking, and- believe it or not- mobile menus!

Slide-out, pop-out, revealing- whatever you want to call them- mobile menus hidden behind an icon toggle are technically modals, and they should be treated as such!

They're definitely good patterns to pull user's attention to specific content (especially when they quite literally block other content)- but there are some features they need to be considered a11y compliant.

1. On open, autofocus the first focusable element in the modal dialog.
2. While open, limit mouse and keyboard focusability to _only_ the content within the modal dialog.
3. On close, autofocus the element that initially triggered the modal to open.
4. When opened, the modal dialog and content should be appended to the end of the DOM.

Now, there are a lot of ways to accomplish this. I just wrote an [article](https://dev.to/drewclem/building-an-accessible-modal-in-vue-2d2a) about how to do this in Vue, if you're interested in implementing this into your Vue project.


## Accessible Menus (navigation submenus)
Collapsible/hover-able navigation menus are another pattern that eat the web up. They make sense. Designers/marketers want to save space [above the fold](https://www.google.com/search?q=above+the+fold&oq=above+the+fold&aqs=chrome..69i57j0i512l4j46i512j46i175i199i512j0i512l3.2040j0j4&sourceid=chrome&ie=UTF-8), and they do that by hiding submenu items underneath or behind their parent menu item.

However, this exposes a lot of room for accessibility errors to come into play. It's easy enough to reveal a menu with a mouse hover, but what about for people who use assistive technologies and navigate with their keyboard?

Does `.menu-item:hover` apply to when a submenu item is keyboard focused? No, it doesn't. That leaves your assisted users possibly reading top-level non-clickable menu items that go nowhere and being given no context as to why they don't go anywhere.

[Heydon Pickering](https://www.smashingmagazine.com/author/heydon-pickering/) has a fantastic [Smashing Mag article](https://www.smashingmagazine.com/2017/11/building-accessible-menu-systems/) where he walks through, in detail, how to build an accessible compliant menu and submenu navigation system.

## Semantically correct HTML
The last, and surprising thing, on this is semantically correct HTML. It's surprising that this one needs to be mentioned, because structurally sound HTML should be the default for anyone coming out of a bootcamp or grad school- but, somehow, it isn't.

Getting your HTML right can have a huge effect on your assisted users experience. It's very common to wrap everything in a div, and before you know it, you have div soup.

HTML has specific elements with some accessibility baked into them. So, why not use them?

We all know about the header and footer, but how often do you forget to wrap your main content between the two in the `<main>` tag? I know I have, more than I care to admit.

There are other HTML patterns to remember too:
- Only have a _single_ `<h1>` tag per page
  - There was a rumor/myth that perpetuated pretty far into the tech community that `<section>` tags reset the page reader and that you could have multiple H1s on a page. This isn't true. There was a proposal for such, but it was never implemented.
- Keep your heading tags in order
  - You should only use your heading tags in an ascending order (by number). H1's should only be followed by H2's. H2's should only be followed by H3's. H3's should only be followed by H4's. Rinse and repeat. 
- Separate different generic content areas with `<section>` tags with proper headings. This lets your user know the content they're about to consume (while it may be related) is separate from what they just engaged with.
- Use `<article>` tags to separate content that could exist independently of the rest of the content, e.g., forum post, a blog entry, etc..

There is a lot more that goes into writing proper HTML. It would take an entire novel (and some do exist) on how to write each section the right way, but keep things like this in mind when you're building, and overtime, you'll probably notice the quality of your HTML increasing while the effort to do so decreases with each project!

Here's a [list](http://www.springboardseo.com/resources/what-is/html-elements-list-complete.html) of HTML elements you can use to check when and if you're using the right element.

A simple page could look something like this:
```html
<body>
  <header>
    <nav>
      <ul>
       <li>
        <a href="/">Menu Item</a>
       </li>
      </ul>
    </nav>
  </header>

  <main>
    <h1>Page Title</h1>
    <article>
      <section>
        <h2>Section title</h2>
        <p>This would be your content description area. 
      </section>
    </article>

    <aside>
      <h2>Side Navigation</h2>

      <ul>
       <li>
        <a href="/">Menu Item</a>
       </li>
      </ul>
    </aside>
  </main>

  <footer>
    <nav>
      <ul>
       <li>
        <a href="/">Menu Item</a>
       </li>
      </ul>
    </nav>
  </footer>
</body>
```


## Summary
Accessibility is important. Not only to those who need it, but also for your business. There's an entire discussion around how better accessibility can increase traffic, revenue, yadda yadda- but let's put it in numbers pertaining to your business.

>Fines up to $55,000 for the first violation and $110,000 for each subsequent violation.
Those who receive Federal funding could have those funds revoked for being in non-compliance. It’s not anything you want to ignore. 
> --[GetADAAccessible.com](https://getadaaccessible.com/ada-compliance-law-and-penalties/)

Holding your company card a little closer right now? I would be.

I'll be the first to admit that I build a lot of websites _incredibly incorrectly,_ from an HTML perspective. But the growth comes from knowing you can do better, and then striving to do so. If you're reading this article, then you're on that right path!

As developers, it's our responsibility to make the knowledge and entertainment on the web available and accessible to everyone. I try to take that responsibility seriously. Do you?