Home

Thunder-Access

What is it?

This package separates accessibility features from your scripts and templates. Basically, it comes down to a separation of concerns, for better readability and maintainability. Read more about the benefits of using this package, or read on for a more thorough explanation.

HTML content is machine-readable, whereas CSS styles visually present that content in a human-readable way. By the same token, accessibility features exist to present that content to the blind. In this way, you might even say these features are like styles for the blind. At this point, it's common knowledge among developers that embedding styles in HTML is a bad practice. So, why do we still do it for accessibility? Not only is it distracting to read, but it quickly becomes repetitive and difficult to maintain. We need a solution that provides an extra layer to presentation, an "accessibility layer," if you will. That's where this package comes in.

<button class="menuBtn">
  <img class="menuIcon" src="bars.png"> Menu
</button>

addAccessibilityRules({

  methods: {
    toggleMenu: utils => utils.toggleExpanded('.menuBtn', '#Menu')
  },

  rules: {

    '.menuBtn': {
      aria: {
        owns: 'Menu',
        haspopup: true,
        expanded: false
      },
      mouse: {
        click: ['toggleMenu']
      }
    },

    '.menuIcon': {
      aria: {
        hidden: true
      },
      attr: {
        alt: '',
        tabindex: -1
      }
    }

  }
})

The above code will assign a click event listener to the button and output the following HTML in the browser:

<button class="menuBtn" aria-owns="Content" aria-haspopup="true" aria-expanded="false">
  <img class="menuIcon" src="bars.png" alt="" tabindex="-1" aria-hidden="true" /> Menu
</button>

Read more about how to use it by reading the documentation.

What are the benefits?

Up front, the most noticeable benefit is that you will no longer have a need for cluttering your template files with excessive attributes, nor your script files with common keyboard navigation functions. All this clutter can be removed and neatly organized in a separate file altogether, so it can be easily maintained and shared across many templates.

Another benefit is the ability to add these features to your markup even if you have no control over the original templates. We've all been there - we just got introduced to an existing project that's messy and hard-to-follow, and we just can't quite understand where that mysterious <div> is coming from! Well, with a unique enough selector, you don't have to care about where it originates, you can still add any necessary attributes or functionality to it. You don't even have to worry about when it loads, because the rules always update when a change in the DOM is detected.

<div id="Page">
  <div>This darn div</div>
</div>

addAccessibilityRules({
  rules: {
    '#Page > div:first-child': {
      aria: {
        hidden: true
      }
    }
  }
})

And, like magic, inspect the element in your browser to see:

<div id="Page">
  <div aria-hidden="true">This darn div</div>
</div>

Finally, arguably the best benefit of all is that you don't have to worry about compatibility. This package is framework-agnostic, and ought to fit right in with any component system thanks to the root property, which allows you to scope the rules to a specific root element. And if you have existing accessible HTML, have no fear, these rules will not interfere with it. That's because anything added directly to your markup is considered "inline" and will take priority over the rules you add. Basically, it behaves just like CSS!