In my previous post about Accessible Landmarks, it was noted that presently a footer scoped to the body element is not exposed as a landmark in Webkit. So, to allow people using VoiceOver to discover footers with their intended landmark status, a role="contentinfo" would need to be added to the element.

What I should have been more mindful to do is verify if there was an open bug with Webkit for this. Fortunately Paul J. Adam filed an issue in October 2018 regarding this lack of expected role.

Today, I added a comment to Paul’s open issue because while footer is not exposed as a landmark in Webkit, the address element is in both Safari and Chrome on macOS (my comment was already made into a new issue).

To add a bit more complexity, address is only surfaced as a landmark with VoiceOver. With Chrome on PC, paired with NVDA and JAWS, footer is correctly announced as contentinfo (which it’s not with VoiceOver); address is also not discoverable as a landmark… however Chrome’s accessibility tab does indicate address has a contentinfo role. (deep sigh / heavy breathing)

The address element

Introduced in HTML 3 the address element was originally created to specify “address, signature and authorship” pertaining to the current document.

Looking at the element as defined by HTML Living Standard:

The address element represents the contact information for its nearest article or body element ancestor. If that is the body element, then the contact information applies to the document as a whole.

Per the definitions of the element, it’s understandable as to why Webkit-based browsers (Safari, Chrome) map address to the contentinfo role, especially in regards to its original definition.

However, there was an issue about this in HTML AAM posted 3 years ago, and a change was made. Today HTML AAM indicates that address has no WAI-ARIA mapping, and instead notes that a footer scoped to the body element should receive the contentinfo role.

Additionally, reviewing HTML’s address definition further, it’s noted that:

The address element must not contain information other than contact information.
…
Typically, the address element would be included along with other information in a footer element.

This is more limited to what the contentinfo role is defined as, per ARIA 1.1:

A large perceivable region that contains information about the parent document.
Examples of information included in this region of the page are copyrights and links to privacy statements.

Why all this?

A bug has been filed, and in the meantime role="contentinfo" can be added to footer elements to get VoiceOver to correctly recognize the landmark. And, if you’re using the address element, you can give it a role="group" or role="presentation" depending on if you really think it needs special grouping semantics or not (it probably doesn’t).

So why this post?

Because stuff like this is confusing, and from what I can tell, largely unknown to many developers and accessibility professionals alike.

Many of the designers and developers I talk to, daily, often want to do the right thing. They want to make things accessible and adhere to standards. But, when they try to follow along with the guidelines, and then get unexpected announcements or bugs in their code or UX, they get frustrated.

Frustrated because it feels like old IE-specific CSS hacks.

/* 
  Why did I need this IE7 specific hack, back in the day?

  Beats me...but clearly something was off by 7px...
*/
.call-out { .top: -7px; }

Having to add ARIA attributes to correctly announce native HTML elements goes against the first rule of Using ARIA. It creates situations where accessibility advocates say “do this thing”, and then follow up with “LOL except for…” (not all advocates say “LOL”). While there’s obviously a precedent for this kind of divergent behavior with legacy IE, when talking about modern-day browsers, that’s when the head scratching starts. Didn’t we get past this? Don’t we have a blue beanie day?

Also: “But, if Apple (WebKit) is doing it this way, is that really a bug?”

I get asked versions of that sort of question over and over again. “But Apple designed it this way.” “But Google coded it this way.” “But Facebook has this exact pattern.”

That’s cool. Big thought-leading organizations aren’t always perfect, ya know?

When behavior diverges from standards, whether it be this swapping of roles with address and footer, or per semantics being uniquely altered by CSS, there may very well be explicit intent to do so. And that intent may also be in the best interests of the people who would most benefit from these announcements.

I’m not arguing with that. The end goal is to make optimal UX for everyone. Personally, I just think it makes more sense to try to aim for parity (re: standards) as we live in a multi-device world, where the same content can be loaded (but interpreted differently) on both. The consistency promotes reliability, the reliability and expected behavior bolsters trust that the accessibility criteria one needs to follow actually pans out.

So I’m looking to add some transparency, and doing what I can to put a bit of focus on where expectations don’t necessarily match reality. Whether intentional or not.

Hopefully, doing so will only help everyone. Because with such knowledge, you’ll actually know why content announces or behaves differently between browsers, operating systems, and assistive technology. After all, it’s not your fault if you’ve coded to specifications but things don’t work as expected. Thus, it shouldn’t necessarily be on you to go far out of your way to “fix” such divergences, either.

Anyway, regarding Webkit and contentinfo specifically, I’m already looking forward to when I can update this post and say “hey, never you mind. It’s all good now.”