Author: anne gibson

Posted on

Today’s accessibility lesson

Repeat after me: a menu is not a dialog. Don’t stick stuff in the menu that doesn’t belong there. For example, this select menu:

A select menu that lists states Alabama through Colorado, and then within the menu layer, displays pagination buttons and tells you that you're on page 1 of 7 choices. Also the buttons for pagination are grey icons on a dark teal background, rendering them unreadable.

Whoever designed this overthought the process.

They started with a list that arguably is too big to handle a list of elements. Select menus work best with 3-10 items, and really max out at 25 or the height of the screen.

They recognized that the list was too big, but instead of using a different pattern, they decided to put buttons inside the menu’s list layer. If they were using the native <select>, adding buttons wouldn’t be possible, but they’ve decided to roll their own component. So now they’re responsible for all the accessibility as well as the behavior.

They have fallen down on the accessibility side.

  • The buttons, which represent first page, back one page, forward one page, forward to the end, and refresh, are grey icons on a teal background. They don’t even remotely pass WCAG 1.4.11 Non-Text Contrast – Level AA.
  • The buttons and page number fields aren’t keyboard accessible. That breaks 2.1.1 Keyboard – Level A.

Now, ironically, neither of these failures actually blocks a person with disabilities from using the field because they can still just type in the state that they want and it will filter to that state.

Which raises the big question: if people restricted to have to use filtering, and filtering is the easiest way to choose a state, why bother with the pagination at all?

What they’ve really built, for a keyboard-only user, is an Autocomplete pattern where a filtered set of options displays as the user types. Which works for everyone. And this is a scenario where the user is filling out their own address, so we can be pretty confident that they know what state they are in.

Worst of all, they don’t just use this component when it’s a long list. They use it for short lists too.

A form field for gender which provides options for female, male, choose not to disclose, nonbinary, and other, followed by pagination buttons that are all disabled and indication that you are on page 1 of 1.

The moral of the story is that it’s easier and more efficient to use either a Select menu correctly or an Autocomplete for filtering than it is to try to force a select menu to do things that they’re not designed to do.

Posted on

Today’s short accessibility lesson

56 Super Bowl Rings, 56 Stories is a good article that is also made inaccessible due to its animation.

(Obviously, content warnings for animation.)

If you’re prone to vertigo or migraines, the giant hero image full of spinning things could cause headaches or vomiting, and further down every ring spins, which can bother both the people already named and people with ADHD who may be constantly distracted by the spinning rings.

Making it accessible would have been as easy as adding a “shut off animation” switch in the top right corner of the hero image, but sigh.

WCAG 2.3.3 Animation from Interactions might be a AAA guideline, but when the consequence of not offering it is your users get a migraine, can’t concentrate, or puke on their shoes, you really should implement it.

This is why we can’t have nice things, ESPN.

Posted on

So what do we have here?

I’m migrating content from a number of other sites to keep all my accessibility information in one place. It’s likely to be a mess for a while while I get the migration done. Then hopefully the cobbler’s kids will find some shoes.