Forem: Tryggvi Gylfason

Big Text !== Heading

Tryggvi Gylfason — Mon, 22 Jun 2020 00:35:26 +0000

It's important to create a logical heading hierarchy on pages so users of assistive tech like screen readers can more easily understand and navigate around (screen readers can jump between headings) the page. Big text doesn't always mean the text should be a heading:

Avoid associating the size of text with its status as a heading.

Spin up a screen reader like VoiceOver, Jaws or NVDA and see for yourself if the headings actually make sense.

In VoiceOver, a screen reader user will be presented with this in the rotor headings menu

Check out Screen Reader Basics: VoiceOver from the A11ycasts series on YouTube. It's great!

"heading level 2 Public Playlists" is announced right after "heading level 1 PROFILE" making it clear that Public Playlists is a subsection on the profile page.

One of the best things you can do imo as developer getting into accessibility is learning how people actually user assistive technologies like screen readers. This helps you answer a lot of your own question around accessibility.

Big text !== heading

Invisible Yet Focusable

Tryggvi Gylfason — Sun, 21 Jun 2020 01:25:57 +0000

These two mixins are one of my favorites. Flexible and useful for creating accessible interfaces.

/*
* Hide only visually, but have it available for screen readers:
* https://snook.ca/archives/html_and_css/hiding-content-for-accessibility
*/
@mixin screen-reader-only() {
  position: absolute;
  opacity: 0;
  pointer-events: none;
}

@mixin undo-screen-reader-only($position: unset) {
  position: $position;
  opacity: 1;
  pointer-events: auto;
}

They are quite handy when hiding something visually.

By using mixins rather than classes we can keep working in pure CSS when showing/hiding the elements instead of reaching for JS to toggle classes.

Another benefit these mixins have (over display:none and visibility:hidden) is that the element can still receive focus, and when it does, we can undo the mixin to show the element. Again, no JS needed. In the cards below, try pressing Shift+Tab to jump to the play button on the previous card.

Building Accessible Grids 2

Tryggvi Gylfason — Sun, 21 Jun 2020 00:04:37 +0000

Part 1:

Building Accessible Grids 1

Tryggvi Gylfason ・ Jun 20 '20 ・ 4 min read

#a11y #webdev #html #react

Here's what we'll build in this post. If you are reading on your phone I'm sorry, this wont work! This time we are focusing (😏) on keyboard support.

It's a playlist!

Let's quickly recap the first post. We want to build a composite grid component that can be skipped with a single Tab key press and has keyboard support. Pressing an arrow key will navigate to the next interactive element.

Let's build the playlist HTML.

<div class="grid" role="grid" tabindex="0">
  <!-- header row -->
  <div class="grid__header-row" role="row" aria-rowindex="1">
    <div role="columnheader" aria-colindex="1">
      <button tabindex="-1">Title</button>
    </div>
    <div role="columnheader" aria-colindex="2">
      <button tabindex="-1">Album</button>
    </div>
    <div role="columnheader" aria-colindex="3">Duration</div>
  </div>
  <!-- regular row -->
  <div class="grid__row" role="row" aria-rowindex="2">
    <div role="gridcell" aria-colindex="1">
      <div>Black Parade</div>
      <a href="#" tabindex="-1">Beyoncé</a>
    </div>
    <div role="gridcell" aria-colindex="2"></div>
    <div role="gridcell" aria-colindex="3">
      4:41
      <button class="heart" tabindex="-1">
        <span class="sr-only">Add to your liked songs</span>
        ♡
      </button>
    </div>
  </div>
  <!-- more rows ... -->
</div>

2 out of 3 headers are buttons. Perhaps they are sortable.
First column TITLE contains the song name and list of artists.
Second column ALBUM contains the album link if any (songs can be singles)
Third column DURATION contains the song duration but also a heart button to add the song to your liked songs. The heart should appear when the row is focused/hovered. When invisible it should still be able to receive focus!

The key hierarchy of selectors is this

div[role="grid"]
└── div[aria-rowindex]
    └── div[aria-colindex]
        └── a, button

From any given button or link, we can traverse up its parent chain in the DOM and find which row and column index it belongs to. Let's move focus based on the current focus and the row and column indexes.

The first thing we have to do is remove all the buttons and links from the natural tab order.

const grid = document.querySelector('.grid');

// Remove all buttons/links from the natural tab order
grid
  .querySelectorAll('a:not([tabindex="0"]), button:not([tabindex="0"])')
  .forEach(el => el.setAttribute('tabindex', '-1'));

Now the grid can be skipped with a single Tab key instead of the user having to tab through every link and button in the grid.

Next, let's add a keydown handle to the grid and call a function to move the focus in the direction of the arrow keys.

grid.addEventListener('keydown', (e) => {
    // Prevent scrolling
    if (e.key === 'ArrowUp' || e.key === 'ArrowDown') {
      e.preventDefault();
    }
    if (e.key === 'ArrowUp') moveFocus(grid, 'up');
    if (e.key === 'ArrowDown') moveFocus(grid, 'down');
    if (e.key === 'ArrowLeft') moveFocus(grid, 'left');
    if (e.key === 'ArrowRight') moveFocus(grid, 'right');
});

function moveFocus(grid, direction) {
  const hasFocusableElement = ensureFocusableElementInGrid(grid)
  if (!hasFocusableElement) return;
  if (direction === 'up') focusUp(grid);
  if (direction === 'down') focusDown(grid);
  if (direction === 'left') focusLeft(grid);
  if (direction === 'right') focusRight(grid);
}

The first thing we do before moving the focus is call ensureFocusableElementInGrid to make sure that a focusable element is present in the grid.

function ensureFocusableElementInGrid(grid) {
  const firstElem = grid.querySelectorAll('a, button')[0];
  const currentFocusable = grid.querySelector(
    '[tabindex="0"]') || firstElem;

  // Happens if the grid does not contain any interactive elements.
  if (!currentFocusable) {
    return false;
  }
  currentFocusable.setAttribute('tabindex', '0');
  return true;
}

Now, let's look at

focusUp and focusDown:

find the currently focused element
find the next cell in above/below row that has interactive elements
If found, focus the first interactive element in the cell if going down and the last interactive element if going up.

focusLeft and focusRight require an extra step:

find the currently focused element
extra! focus the next interactive element in the cell if it exists.
Otherwise, find the next cell in the current row that has interactive elements
If found, focus the first interactive element in the cell if going right and the last interactive element if going left.

It's a bit of code involved but it's quite reusable:

Here is a React version

Wrapping up

I hope you can see how this can be extrapolated to lists or different kind of grids or tables. Maybe a spreadsheet for example.

The same basic principles apply.

Remove all interactive elements within the composite component from the tab order
On arrow key press, find the next element that should get focus
Move the focus using roving tabindex

Edit
It's worth mentioning the ARIA Grid: Supporting nonvisual layout and keyboard traversal article from Facebook that touches on very similar things.

Building Accessible Grids 1

Tryggvi Gylfason — Sat, 20 Jun 2020 21:09:35 +0000

Interactive Element: Any html element that can receive focus. For example the a, button and input elements are interactive by default. Any element can be made interactive by adding a tabindex="0 attribute to it. Similarly, any element can be made non-interactive by using tabindex="-1".

Part 2:

Building Accessible Grids 2

Tryggvi Gylfason ・ Jun 21 '20 ・ 4 min read

#a11y #webdev #html #react

Background

Building accessible lists and grids on the web is unfortunately difficult.

In frameworks like React, where a Grid component does not necessarily know about or control its children, it can be even harder.

Using a <table> and associated child elements is the right choice sometimes. Other times it's not. These elements are awkward to lay out and more importantly impose limitations on the DOM structure . More complex grids may need to use <div>s.

Grids should be navigable with arrow keys. You can read about the expected keyboard support for data grids in the WAI ARIA practices.
Grids should be skippable with a single Tab key press. They are composite components. You can read more in this excellent thread

Devon Govett

@devongovett

There's a very common misconception that pure HTML with no JS is somehow more accessible. Unless you're building a very basic content site with no interactivity, that's just plain false!

Until the platform improves, you need JS to properly implement keyboard navigation.

Thread.

18:15 PM - 20 Jun 2020

One way to add keyboard support to grids is to base the navigation on the current state of the DOM instead of the framework state (React and Vue for example).

Aria attribute DOM based way

<div role="grid">
  ...
  <div role="presentation">
    ...
    <div role="row" aria-rowindex="1">
      ...
      <div role="presentation">
        ...
        <div role="gridcell" aria-colindex="1">
          ...
          <a tabindex="-1"></a>
          <button tabindex="-1"></button>
        </div>
      </div>
    </div>
  </div>
</div>

Let's walk through how this is done on a high level. In the next post we'll go more concrete and actually implement this.

Create the root grid element
- Give grid the role="grid" attribute.
- Give grid tab-index="0" so users can navigate to it (remember to add some CSS focus styles. E.g. a border or an outline that indicates the grid is in focus)
Add rows to the grid
- Give row role="row"
- Give row the correct aria-rowindex (starts with 1)
Add cells (a row,col combination) to the rows
- give cell either a role="columnheader" if it's a column header, or a role="gridcell" if it's a regular cell
- Give cell the correct aria-colindex attribute (starts with 1)
Make sure all elements between grid -> row -> gridcell that do not have an explicit role, get role="presentation" added to them.
- This removes those elements from the accessibility tree and ensures screen readers can correctly interpret and navigate the grid.
Make sure that all interactive elements in the grid have tabindex="-1" attribute
- This removes them from the natural tab order of the page and ensures that users can jump over the whole grid with a single Tab key press if they want to skip it.
Add a keydown listener to the root grid element (role="grid") and respond to key presses like the arrow keys.
Once an arrow key is pressed we choose what to focus next in the DOM. More on that in a bit.

The DOM based approach gives us the benefit of the focus management being transparent to the grid and its child components. If a new interactive element is added to a cell in the grid it will work without modification.

The downside is frameworks like React can change the DOM at any time. Because of this, the first thing that is done in keydown event handler before moving any focus is ensuring that a focusable element (with tabindex="0" attribute) actually exists in the grid. If it doesn't exist, fall back to the first interactive element in the grid.

This should not happen much unless your framework is adding/removing cells from the DOM frequently. I have not seen problems with this in a virtually scrolled, sortable/filterable grid that loads more data on scroll so I expect this is will work well in most cases.

Roving tabindex

Now that we have found the currently focused element in the grid we need to decide which element to focus next. If we find that element we move the focus to that element:

tabindex="0" -> tabindex="-1" on the currently focused element
tabindex="-1" -> tabindex="0" on the next element to focus
call focus() on the next element.

This technique is called roving tabindex. You can read more about it in the WAI-ARIA Authoring Practices or check out this excellent video from the A11ycasts series on the Google Chrome Developers YouTube channel.

Moving focus to the next element

So how do we find the next element to focus in a reliable way? This depends on what the grid actually is. If the grid is a spreadsheet it might make sense to focus the next cell element. But if the grid is a collection of links and buttons structured in a table - for example a playlist on Spotify, then jumping to the next interactive element would make sense.

In the next post I'll go through a concrete implementation keyboard support of a grid containing a and button elements.

Wrapping up

As long as

This hierarchy of selectors is in place

[role="grid"]
└── [aria-rowindex]
    └── [aria-colindex]
        └── a, button

aria-rowindex/aria-colindex are 1-based and sequential

Then the keyboard navigation will work. Additional wrapper elements between each layer do not matter.

Building accessible grids and lists can be daunting and too many don't bother. Fortunately adding keyboard support can be done in a generic, framework and use-case agnostic, repeatable way that is likely to survive future changes to the components without breaking or needing modification.

In the next post we'll implement a grid with proper keyboard support using this method.

Part 2:

Building Accessible Grids 2

Tryggvi Gylfason ・ Jun 21 '20 ・ 4 min read

#a11y #webdev #html #react