The Accessibility of HTML

Presented by Scott O'Hara of The Paciello Group

At #a11yTO Conf 2019.

<speaker name=scott list=self />

<ul id=self>
  • Work at TPG: The Paciello Group
  • Work on W3C specifications...
  • Write, and test, and write about testing...
</ul>

I have (create?) trust issues...

Skype bandit animated emoji

maybe you should too?

<center>

HTML

</center>

You may have heard (or said)...

HTML is accessible by default.
If only [someone] had used HTML, [they would] get accessibility for free!
Semantic HTML is accessible HTML.

These can make for quick tweets, no?

The Reality is:
such statements are not entirely true.

Notes:

Which is unfortunate, as they're simple to state. Easy to remember.

But a lot of accessibility isn't simple. Not really. And it's important to be forthcoming with that.

Accuracy Matters

See: It Depends™

Notes:

Being accurate helps us build trust with teams that may be resistant to process changes, or individuals who may not have "bought into" accessibility, inclusive or universal design practices.

We don't need to be perfect. I would not suggest that as it's impractical.

But accessibility is harder than just using semantic HTML. One can easily use semantic HTML and still come out with garbage UX. Whether because it was used incorrectly, or that there's nothing particularly "accessible" about the HTML that's been used.

<argument>
<del>HTML is accessible by default</del>
<ins>HTML is semantic by default</ins>

thinking emoji

A Quote:

Semantic HTML usage rarely has impact on users; users are instead impacted by things like accessibility mappings, visual presentation, and the like...

Trivia: cite attribute (see semantic HTML) not consistently exposed to AT.

Semantics are good

We SHOULD use semantic HTML.

And when we use semantic HTML it MUST be for its intended purpose.

BUT

The Semantics of HTML are merely part of a whole

With all parts in place, the accessibility of HTML is more nuanced than 280 characters allow.

Notes:

The semantics of HTML are beneficial to people. They allow developers to know what element they should use to markup their documents, which will produce the necessary UI, or building block for more complex UI.

These "semantics" are for people but the "semantics" of what a button is and should do, are irrelevant to end users. To expand on: implicit rendering and a11y api mappings, as well as the author defined functionality, are what make the button usable and accessible (or not)...

</argument>
<evidence>

Some of said parts:

<ol id=toc>
  1. ARIA
  2. CSS
  3. HTML (semantics)
</ol>

1. ARIA

Blame it all on ARIA

Notes: There are three truths to ARIA...

1. ARIA can improve the accessibility of inaccessible markup. 

<div role="button"
  tabindex="0"
  onClick="pretend_to_button!()">
    JS button be for hooray!
</div>

2. ARIA can be misused, breaking user expectations. 

<a href="url.html"
  aria-haspopup="true"
  aria-expanded="t/f">Link Text</a>

  <ul> <!-- not a menu -->
    <li><a href="url2.html">Link</a>
    <!-- etc -->
  </ul>
Notes:

As APG principal 1 states: "a role is a promise".

What sort of promise is being made, what should a user expect when they're presented with a functional link, that can also indicates it should somehow open a menu...

A screen reader may even provide instructions for interacting with that menu, but it's not a menu the user would be presented with, but rather a standard list of more links...

Not all drop downs are menus, nor should they be.

3. The ARIA WG defines the accessibility API mappings for many native HTML features.

Animated gif of someone cutting into what looks like a resting pug, but it's in fact made of ice cream. the camera then changes to an actual dog's face which looks to be filled of utter disbelief and abject horror.

Maybe this truth makes you feel how this (real) dog looks?

A brief explanation of Accessibility API Mappings (AAM)

HTML-AAM

HTML Accessibility API Mappings (HTML-AAM) defines how user agents map HTML elements and attributes to platform accessibility APIs.

Platform APIs

  • Windows: MSAA & IA2 (Microsoft Active Accessibility & IAccessible2)
  • Windows: UIA (User Interface Automation)
  • Linux/GNOME: ATK (Accessibility Toolkit)
  • Apple: AX API

A Mapped Element

summary element mappings, largely all mappings expose it as a toggle button of some sort.
Notes: Here we have the a11y platform mappings for the summary element. Keeping it simple, basically all the platforms map Summary to a type of toggle button. Except for Webkit. They map it to a "disclosure triangle".

Cool.

No Mapping

picture element table showing no exposed mappings.
Notes:

Sometimes there is no accessible information to convey about an element. that's not to say the element doesn't DO anything, or associated elements can't have an impact on accessibility.

but not everything is exposed to the a11y api, and that's ok.

The picture element serves as a mechanism to display an appropriate source or fallback image. The nested image is what is exposed to the browser's a11y tree.

Use WAI-ARIA Mapping

main element mappings
Notes:

This means that the accessibility API mappings for a particular element are NOT mapped by HTML alone. Rather, the ARIA Working group defines the mappings for such elements (of which there are many that defer to ARIA) over in the Core AAM.

Core-AAM

A central location for UA implementors to reference appropriate role, state and property mappings.

As with ARIA 1.0, Core-AAM 1.0 became
a W3C recommendation in March 2014.

Notes: why do we need this? because while use for ARIA is quite prevalent in HTML, other host languages should be able to leverage it if so desired.

Currently on Working Draft 1.2

Those WAI-ARIA Mappings

showing core aam table of mappings for listitem, log, main and marquee roles.

New roles for old markup

  • associationlist
  • strong
  • emphasis
  • deletion
  • insertion
  • code
  • generic (please do not use)
  • more...
Notes:

A big part of ARIA/Core AAM 1.2 was to achieve role parity with many of HTML's elements.

Doing so is important for working with custom elements, and defining these custom elements via their ElementInternals (see also: accessibility object model).

It's also worth noting that as these new ARIA roles are being made, definitions are being created to map to a11y apis, which can then upstream back to make their HTML counterparts more accessible.

Homer Simpson standing atop stacked barrels within a crowd of people, with his beer mug raised to the sky and caption stating: to ARIA! The cause of, and solution to, all our accessibility problems
From Jon Whiting's 2017 WebAIM article

2. CSS

Skin deep semantics

CSS can impact a11y in many ways...

But I'm not talking about color contrast today.

CSS = Style, HTML = Semantics

  • <font>
  • <blink>
  • <center>
  • <big>
  • <marquee> *
  • [bgcolor]
  • [background]
  • [bgsound]
  • etc.

* We'll see you over in ARIA, marquee...

<blockquote cite="https://html.spec.whatwg.org/#obsolete">
Use appropriate elements or CSS instead.
</blockquote>
Notes:

Collectively we look at CSS as being for styling, and HTML being for structure/semantics. It's why HTML 4/5 deprecated many "presentational" elements.

However, not all style is merely for presentation.

CSS + HTML = Semantics Some CSS + HTML = Accessibility

Notes:

User Agents style a good chunk of HTML by default because without it, visually there'd be no difference, and without any visual difference how can one tell a button from a link from a div?

Additionally, styles like user defined High Contrast mode styles, will specifically target certain HTML elements to color them appropriately. But beyond that....

CSS !important

Because certain styling MAY be necessary for AT to properly announce some markup.

While other styling MAY obscure or destroy meaning.

Provide Meaning:
display: table etc
list-style: ___
Obscure Meaning:
visibility: hidden
display: none
Destroy Meaning:
display: contents
Notes:

Without table, table row and cell styling, browser heuristics can just drop their roles, deciding for you that you're no longer creating tabular data. This must be a layout table.

As far as lists are concerned, there's zero difference between how lists are exposed to the accessibility tree, but for their list markers. Semantically different, yes. But you remove those list markers, it's all just lists, except for with Webkit, where they've decided for you that without list markers, those aren't lists at all.

Display contents can be like a `role=presentation !important` on HTML. Do not use it on content that needs to be properly exposed.

3. HTML

Et tu, HTML?

Scene from the movie office space where the Bobs ask 'what is it you (in this context, HTML) do here?'

HTML does what it's supposed to do It's semantic.

<reprise>

Semantics are good

We SHOULD use semantic HTML.

And when we use semantic HTML it
MUST be for its intended purpose.

</reprise>

Strong Semantics

  • <a href="...">
  • <img src="..." alt="not a tag">
Notes:

There are certain features of HTML that have strong implicit semantics, and cannot easily have their semantics (functionality) overwritten, if at all.

For instance, as long as the anchor element has an valid href attribute, you are going to have to jump through some hoops, beyond just overwriting its role, to negate its implicit semantics that dictate functionality.

Images are rendered in a way where overwriting their implicit a11y mappings and semantics can be far more trouble than it's worth. Just use the elements you need instead!

Conditional or
Pedantic Semantics

Question: which of these elements has the same mappings as a div?

  • <section> (w/out accName)
  • <header> (not scoped to body)
  • <footer> (not scoped to body)

Oversold Semantics

Elements that don't actually work as specified, or convey any a11y mappings.

  • menu
  • hgroup
Notes:

hgroup is currently undergoing work that may result in it being useful in hopefully the not to distant future.

The menu element, originally meant as a "website menu" e.g. early nav...

html 3.2
These elements have been part of HTML from the early days. They are intended for unordered lists similar to UL elements. User agents are recommended ... MENU elements as single column menu lists. In practice, Mosaic and most other user agents have ignored this advice and instead render MENU in an identical way to UL elements.

html 4
deprecated menu

html 5
brought back menu and introduced menuitem & other functionality. some of which was implemented in firefox. All of which was ignored by everyone else.

2015 - 2017
menu essentially reverted to another way to UL, like it was in HTML 3.2, but now its do-nothing "semantics" are meant for it to be treated as a "toolbar"!

2019
All browsers treat <menu> like a div, and thus list items within are not exposed as being part of a list. Firefox will treat menu as a list in firefox 71. Chrome has noted it's a bug, and doesn't follow the expectations from the spec, but they need someone from the a11y team to weigh in on this because... Webkit remains silent in their bug tracker as one should expect.

Like CSS, and ARIA,

Semantic "Accessible" HTML can be misused to make inaccessible user experiences

a not allowed icon over a dreamworks troll character. i do not intend to be trolling you.
  • lol forever title attribute
  • be careful with autofocus
  • using <video autoplay>
  • <a> wrapping highly structured content
  • and other HTML features which may have implementation gaps or bugs

</evidence>
<closing>

So HTML isn't exactly / always accessible by default...

It is one part of what makes accessible and inclusive user experiences.

  • A11y API mappings
  • CSS
  • Semantics
  • And us (hey, i didn't mention us before...)

What do we do?

  • We teach and write
  • We can get involved with standards
  • We can share and propose new ideas
  • We report bugs, and gaps, and fix them but good
Notes:

We clearly care. We wouldn't be here today if we didn't.

If I'm wrong about you, I apologize for implying you care.

We do these things though, even just a little bit, it can and will help.

And for every bit we help make things better, the easier our jobs get, and the easier we've made it for other people to do what they want to get done.

</closing>
<thank-you />

Where to file bugs, questions and participate in issues and discussions

Links to references