Debugging Broken Accessibility

This talk is not about:

how to test
how to fix specific bugs
tooltips

Why debugging?

The accessibility process (imagination)

Learn: semantic HTML, tabbing, yay!
Test
Fix bugs
Include everyone!

Retsuko is starry-eyed and eager, surrounded by bishie sparkles

The accessibility process (reality)

Learn: semantic HTML, tabbing, yay!
Testing happens
...
...
... ... what is aria-required-children??!

Aggretsuko staggers under a huge pile of papers with deep shadows under her eyes, surrounded by little blue flames

My learning process:

This isn't made any easier by the way a lot of us approach learning (or maybe it's just me): the way I learned web dev, javascript, and accessibility was largely isolated, because:

I was afraid to ask for help, yay imposter syndrome
Often companies only have one accessibility person, and even that is if you're lucky (I didn't always work at Microsoft).

As a result, I ended up struggling through learning a lot of this on my own, which is a very lonely and stressful way to learn.

It also causes a lot of doubts: am I missing something really obvious? Am I looking at the right things? Do other people find this hard too? There must be a really obvious solution to this that I'm just not smart enough to see, etc.

I really don't recommend this way of learning.

This talk is about:

aggretsuko, an aggrieved red panda, working furiously at her computer as papers go flying

frustration.

A better option:

Retsuko looking at her computer while Haida watches over her shoulder, both looking nonplussed.

Let's do this.

Our Toolbox:

Inspect
Assistive Tech
Specs
Github issues

The bugs:

Semantics
Focus
Oops
Nope

Bug 1: the dreaded <table>

screenshot of a simple-looking table with information about books

"NVDA's table commands aren't working properly..."

Tools

Inspect
Assistive Tech
Specs
Github issues

Inspect with Firefox:

screenshot of the table being inspected in Firefox, with the table node highlighted, and one of the cells highlighted as a div with a class of row-header. Opens working example in a new window.

Compare in the spec:

screenshot of the ARIA spec for the table role, highlighting the required owned elements section with row and rowgroup. Opens ARIA spec in a new window.

Bug 2: the screen reader cursor is "lost"

An open file actions dropdown menu with three actions: save, edit, and delete

Tools

Inspect
Assistive Tech
Specs
Github issues

Does it reproduce?

table of testing results for virtual cursor vs. tabbing when focus is lost. Full HTML version in linked article under results heading. — Full write-up at sarahmhigley.com

Observing focus changes

Menu example page


						document.activeElement


						document.addEventListener('focusin', () => {
							console.log(document.activeElement);
						});

Bug 3: the screen reader should say...

The same open file actions dropdown menu with three actions: save, edit, and delete

"VoiceOver isn't reading the index of the menu items"

Tools

Inspect
Assistive Tech
Specs
Github issues

Do NOT do this:

<button role="menuitem" aria-label="Save, 1 of 3">Save</li>

Compare:

The menu button example from the ARIA Authoring Practices

Ask:

A coworker (in a relevant job)
A community (slack, twitter)
User studies

This applies to more than screen readers!

Compare against plain HTML for keyboard, pointer, High Contrast Mode, voice control, etc.

Bug 4: Return of the <table>

Screenshot of same table from example 1, showing truncated cell text with a tooltip containing the full text

"The truncated text is not accessible via keyboard"

Tools

Inspect
Assistive Tech
Specs
Github issues

Is this a good design?

same tooltip on a truncated cell within a table.

Don't let designs get away with begging the question.

A website is not an art gallery.

The same table with a tooltip, displayed inside an ornate frame

To debug this one, there is no trick. There is spec you can go to.

The root cause of this isn't technical, but a design flaw: the idea that a uniform height is more visually pleasing + that this matters more than understandability and access.

No one is going to your website to appreciate the art of your graphic design. They want to consume your content or use your app.

Let's be clear, this affects a number of people:

Low vision/zoom -- even if you can get the tooltip, it's more work to read each line, and likely each line will need a tooltip to read the full text
Someone who relies on the keyboard, switch, eye gaze
ANYONE ON MOBILE/TABLET, JESUS CHRIST
Higher cognitive load to read lines, can't read all of them at once, so potentially short term memory issues too. It's like playing a terrible version of the memory card game.

Digging up roots

The value of front-end knowledge

screenshot of Firefox dev tools showing the incorrect table accessibility tree from bug 1

document.activeElement

Accessibility practitioner yells at cloud

meme of Abe Simpson shaking his fist with the headline Old Man Yells At Cloud.

Look at the structure, not the individuals:

Is training in accessibility available?
Is basic accessibility knowledge considered when hiring?

Bad Assistive Tech assumptions

<button role="menuitem" aria-label="Save, 1 of 3">Save</li>

remember this?

Who is doing the testing, and who decides what the experience should be?

Are disabled people hired?
Do they stay?
Are they listened to?

Tooltips in the real world

a different table with example content, a truncated column, and a tooltip

Is accessibility part of choosing 3rd-party libraries?

a github label search on an anonymous repository showing 41 open issues and PRs labelled with accessibility. — Check github for accessibility-related activity

Github checks anyone can do:

Issue labels
Fixed, stale, or closed
Discussion quality

With some help:

A screenshot of a form field collecting github repository URL information for ant-design, under the heading 'Find accessibility stats by github repository'.

Try it out

This sounds hopeful, but...

screenshot of multiple github labels and responses on accessibility issues, including a bot auto-closing an issue as stale; issues labeled won't fix, enhancement, and low priority; and a contributor commenting that it's something they would like, but not on the roadmap.

This talk is about:

frustration.

Aggretsuko, still in office mode with an obviously fake smile, holds her coffee cup while entirely surrounded by background flames. It really seems like her eye must be twitching.

...lots of frustration.

...but it's better with friends.

aggretsuko screams into a karaoke mic while sharing wine with two of her friends

slides:

smhigley.github.io/slides/debugging-a11y

contact:

@codingchaos