Bug 190138 – AX: <footer> HTML5 tag not reading as ARIA Landmark to VoiceOver

• Component: Accessibility
• Status: RESOLVED FIXED

[Paul J. Adam]

Created attachment 351243 [details]
footer not shown in the VoiceOver Landmarks Rotor

Steps to Reproduce:
1. Visit http://pauljadam.com/demos/html5-structural.html in Safari 12 on macOS Mojave
2. Turn on VoiceOver 
3. Use VoiceOver Rotor Landmark navigation to move focus to the <footer> landmark. 

Expected Results:
VoiceOver moves focus to the <footer> using Rotor Landmark navigation. 

Actual Results:
VoiceOver does not move focus to the <footer> using Rotor Landmark navigation. 
The <footer> is not read as an ARIA Landmark to VoiceOver.

[Radar WebKit Bug Importer]

<rdar://problem/44907695>

[Scott]

Adding onto this:

As I've also encountered the lack of landmark that Paul has outlined per the footer scoped to the body, I've also come to realize that Webkit exposes the address element as a contentinfo landmark instead.

Tested with Safari 12 + Chrome 72 (mac and PC), the accessibility inspectors in both browser's dev tools expose the address element as contentinfo. Thus VoiceOver treats the address element as a landmark.

With Chrome on Windows, address is also exposed as having a contentinfo role, but JAWS and NVDA ignore this, instead only surfacing <footer> as a contentinfo landmark.

https://codepen.io/scottohara/pen/xMaJQO


Expected results:
Address should not be exposed as a contentinfo landmark in Webkit.
Footer (when scoped to the body element) should.

[chris fleizach]

(In reply to Scott from comment #2)
> Adding onto this:
> 
> As I've also encountered the lack of landmark that Paul has outlined per the
> footer scoped to the body, I've also come to realize that Webkit exposes the
> address element as a contentinfo landmark instead.
> 
> Tested with Safari 12 + Chrome 72 (mac and PC), the accessibility inspectors
> in both browser's dev tools expose the address element as contentinfo. Thus
> VoiceOver treats the address element as a landmark.
> 
> With Chrome on Windows, address is also exposed as having a contentinfo
> role, but JAWS and NVDA ignore this, instead only surfacing <footer> as a
> contentinfo landmark.
> 
> https://codepen.io/scottohara/pen/xMaJQO
> 
> 
> Expected results:
> Address should not be exposed as a contentinfo landmark in Webkit.
> Footer (when scoped to the body element) should.

Made a new bug for the address issue:
https://bugs.webkit.org/show_bug.cgi?id=194654

[chris fleizach]

Created attachment 362043 [details]
patch

[Joanmarie Diggs]

Comment on attachment 362043 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=362043&action=review

> Source/WebCore/accessibility/AccessibilityObject.cpp:412
> +    case AccessibilityRole::Footer:

Is this going to cause all footers to be treated as landmarks? According to the HTML-AAM, we do want to treat footers scoped to the body element as landmarks (specifically contentinfo) [1]. But not when it's scoped to the main element, a sectioning element, or a sectioning root element other than body. [2]

[1] https://w3c.github.io/html-aam/#el-footer-ancestorbody
[2] https://w3c.github.io/html-aam/#el-footer

[chris fleizach]

(In reply to Joanmarie Diggs (irc: joanie) from comment #5)
> Comment on attachment 362043 [details]
> patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=362043&action=review
> 
> > Source/WebCore/accessibility/AccessibilityObject.cpp:412
> > +    case AccessibilityRole::Footer:
> 
> Is this going to cause all footers to be treated as landmarks? According to
> the HTML-AAM, we do want to treat footers scoped to the body element as
> landmarks (specifically contentinfo) [1]. But not when it's scoped to the
> main element, a sectioning element, or a sectioning root element other than
> body. [2]

We still ignore footers (completely) if it doesn't match this criteria

    if (!isDescendantOfElementType(articleTag) && !isDescendantOfElementType(sectionTag))
        return AccessibilityRole::Footer;

To confirm, if it's inside a main element should we ignore completely? Or should make sure it's not a landmark

Are article/section the only "Sectioning" elements we need to worry about?

> 
> [1] https://w3c.github.io/html-aam/#el-footer-ancestorbody
> [2] https://w3c.github.io/html-aam/#el-footer

[Joanmarie Diggs]

(In reply to chris fleizach from comment #6)

It would be helpful if Scott (who happens to be one of the editors of the HTML-AAM) could clarify and correct me if I'm wrong.

In the meantime, what's in the spec seems to suggest that the goal is to have at most one footer-based landmark ("scoped to the body"). This one landmark footer should be exposed as if it had the ARIA contentinfo role. I'm basing that on what I read here: https://w3c.github.io/html-aam/#el-footer-ancestorbody

If my read is correct, rather than add AccessibilityRole::Footer to the landmark roles, could we instead just assign the footer scoped to the body element AccessibilityRole::LandmarkContentInfo?

Reading the next part of the spec (https://w3c.github.io/html-aam/#el-footer), my take is the following: If its inside a main element, or inside a section-like thing, including article and section), then it is NOT a landmark. Looking at the mappings, it should be treated as if it were a div. Mind you, I don't think it should be ignored as if it were a div without a role. I say this because IA2 and ATK each have platform footer roles, and some ATs might be interested in saying that element is a "footer" when the user navigates into it.

If my read on the second item is correct, then I think the non-landmark footers should have AccessibilityRole::Footer rather than AccessibilityRole::LandmarkContentInfo. Then on your platform, it would be an AXGroup; on mine it should be ATK_ROLE_SECTION (according to the current mappings) or ATK_ROLE_FOOTER, which is what I think it should be. See related 
https://github.com/w3c/html-aam/issues/129.

@Scott, you provided a test case for a footer which should be a landmark. Could you also provide a test case for all the things which should NOT be landmarks (not scoped to the body element)? Then those examples could be used in a Layout Test to be sure we're doing what the spec states. Thanks!

[chris fleizach]

(In reply to Joanmarie Diggs (irc: joanie) from comment #7)
> (In reply to chris fleizach from comment #6)
> 
> It would be helpful if Scott (who happens to be one of the editors of the
> HTML-AAM) could clarify and correct me if I'm wrong.
> 
> In the meantime, what's in the spec seems to suggest that the goal is to
> have at most one footer-based landmark ("scoped to the body"). This one
> landmark footer should be exposed as if it had the ARIA contentinfo role.
> I'm basing that on what I read here:

If the author does

<footer role="contentinfo"> then I believe all this works correctly. This bug is for a <Footer> tag with no other role mapping.

> https://w3c.github.io/html-aam/#el-footer-ancestorbody
> 
> If my read is correct, rather than add AccessibilityRole::Footer to the
> landmark roles, could we instead just assign the footer scoped to the body
> element AccessibilityRole::LandmarkContentInfo?
> 
> Reading the next part of the spec
> (https://w3c.github.io/html-aam/#el-footer), my take is the following: If
> its inside a main element, or inside a section-like thing, including article
> and section), then it is NOT a landmark.

We have the article/section logic, but not "main"

 Looking at the mappings, it should
> be treated as if it were a div. Mind you, I don't think it should be ignored
> as if it were a div without a role. 

It is currently, but we can fix that.

I say this because IA2 and ATK each have
> platform footer roles, and some ATs might be interested in saying that
> element is a "footer" when the user navigates into it.
> 
> If my read on the second item is correct, then I think the non-landmark
> footers should have AccessibilityRole::Footer rather than
> AccessibilityRole::LandmarkContentInfo. Then on your platform, it would be
> an AXGroup; on mine it should be ATK_ROLE_SECTION (according to the current
> mappings) or ATK_ROLE_FOOTER, which is what I think it should be. See
> related 

But presumably with a role description for "footer"?


> https://github.com/w3c/html-aam/issues/129.
> 
> @Scott, you provided a test case for a footer which should be a landmark.
> Could you also provide a test case for all the things which should NOT be
> landmarks (not scoped to the body element)? Then those examples could be
> used in a Layout Test to be sure we're doing what the spec states. Thanks!

[Joanmarie Diggs]

(In reply to chris fleizach from comment #8)

> If the author does
> 
> <footer role="contentinfo"> then I believe all this works correctly. This
> bug is for a <Footer> tag with no other role mapping.

Exactly. The HTML-AAM mapping tables dictate what happens when an ARIA isn't used. When ARIA is used, the Core-AAM dictates what should happen. The links I provided are for the HTML-AAM (i.e. sans role="contentinfo").

> But presumably with a role description for "footer"?

If VoiceOver should say "footer" for the "footer" element when it is NOT used as a landmark, then yeah, you'll probably want an AXRoleDescription of "footer" rather than "group" (which is what is currently in the HTML-AAM). If that is indeed the case, then we should file an issue against the HTML-AAM so that your platform's mapping gets updated and other browser agent vendors can follow suit so VO users get a consistent user experience regardless of browser being used.

[chris fleizach]

(In reply to Joanmarie Diggs (irc: joanie) from comment #9)
> (In reply to chris fleizach from comment #8)
> 
> > If the author does
> > 
> > <footer role="contentinfo"> then I believe all this works correctly. This
> > bug is for a <Footer> tag with no other role mapping.
> 
> Exactly. The HTML-AAM mapping tables dictate what happens when an ARIA isn't
> used. When ARIA is used, the Core-AAM dictates what should happen. The links
> I provided are for the HTML-AAM (i.e. sans role="contentinfo").
> 
> > But presumably with a role description for "footer"?
> 
> If VoiceOver should say "footer" for the "footer" element when it is NOT
> used as a landmark, then yeah, you'll probably want an AXRoleDescription of
> "footer" rather than "group" (which is what is currently in the HTML-AAM).
> If that is indeed the case, then we should file an issue against the
> HTML-AAM so that your platform's mapping gets updated and other browser
> agent vendors can follow suit so VO users get a consistent user experience
> regardless of browser being used.

I looked at that documentation briefly and didn't see mention of landmarks. Do you think a <footer> in a <body> should be marked as a landmark?

[Scott]

(In reply to Joanmarie Diggs (irc: joanie) from comment #7)
> (In reply to chris fleizach from comment #6)
> 
> It would be helpful if Scott (who happens to be one of the editors of the
> HTML-AAM) could clarify and correct me if I'm wrong.
> 
> In the meantime, what's in the spec seems to suggest that the goal is to
> have at most one footer-based landmark ("scoped to the body"). This one
> landmark footer should be exposed as if it had the ARIA contentinfo role.
> I'm basing that on what I read here:
> https://w3c.github.io/html-aam/#el-footer-ancestorbody
> 
> If my read is correct, rather than add AccessibilityRole::Footer to the
> landmark roles, could we instead just assign the footer scoped to the body
> element AccessibilityRole::LandmarkContentInfo?
> 
> Reading the next part of the spec
> (https://w3c.github.io/html-aam/#el-footer), my take is the following: If
> its inside a main element, or inside a section-like thing, including article
> and section), then it is NOT a landmark. Looking at the mappings, it should
> be treated as if it were a div. Mind you, I don't think it should be ignored
> as if it were a div without a role. I say this because IA2 and ATK each have
> platform footer roles, and some ATs might be interested in saying that
> element is a "footer" when the user navigates into it.
> 
> If my read on the second item is correct, then I think the non-landmark
> footers should have AccessibilityRole::Footer rather than
> AccessibilityRole::LandmarkContentInfo. Then on your platform, it would be
> an AXGroup; on mine it should be ATK_ROLE_SECTION (according to the current
> mappings) or ATK_ROLE_FOOTER, which is what I think it should be. See
> related 
> https://github.com/w3c/html-aam/issues/129.
> 
> @Scott, you provided a test case for a footer which should be a landmark.
> Could you also provide a test case for all the things which should NOT be
> landmarks (not scoped to the body element)? Then those examples could be
> used in a Layout Test to be sure we're doing what the spec states. Thanks!


Joanmarie's read on this is correct.

Footer should be promoted to a landmark and announced as contentinfo when scoped to the body element.

It should not be a landmark/announced as contentinfo if an ancestor of:
a main element, or sectioning elements such as: article, aside, nav, or section.
Nor should a footer be announced as contentinfo if an ancestor of a sectioning root element: blockquote, details, dialog, fieldset, figure, or td.

I'll provide a test case within the next few days if still necessary.

[chris fleizach]

Created attachment 362827 [details]
patch

Updated patch

[EWS Watchlist]

Comment on attachment 362827 [details]
patch

Attachment 362827 [details] did not pass mac-ews (mac):
Output: https://webkit-queues.webkit.org/results/11261386

New failing tests:
accessibility/roles-exposed.html

[EWS Watchlist]

Created attachment 362828 [details]
Archive of layout-test-results from ews101 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews101  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[EWS Watchlist]

Comment on attachment 362827 [details]
patch

Attachment 362827 [details] did not pass mac-debug-ews (mac):
Output: https://webkit-queues.webkit.org/results/11261440

New failing tests:
accessibility/roles-exposed.html

[EWS Watchlist]

Created attachment 362830 [details]
Archive of layout-test-results from ews114 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews114  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[EWS Watchlist]

Comment on attachment 362827 [details]
patch

Attachment 362827 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: https://webkit-queues.webkit.org/results/11261465

New failing tests:
imported/w3c/web-platform-tests/webrtc/simplecall-no-ssrcs.https.html
accessibility/ios-simulator/landmark-type.html

[EWS Watchlist]

Created attachment 362831 [details]
Archive of layout-test-results from ews126 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews126  Port: ios-simulator-wk2  Platform: Mac OS X 10.13.6

[chris fleizach]

Created attachment 362886 [details]
patch

[chris fleizach]

Comment on attachment 362886 [details]
patch

@Joanmarie are you able to review now?

[Joanmarie Diggs]

Comment on attachment 362886 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=362886&action=review

> Source/WebCore/accessibility/AccessibilityRenderObject.cpp:2871
> +        if (!isDescendantOfElementType({ articleTag, sectionTag, mainTag, blockquoteTag, detailsTag, fieldsetTag, figureTag, tdTag }))

BTW (for a new/separate bug): Headers fall into the very same mapping pattern. See https://w3c.github.io/html-aam/#el-header-ancestorbody versus https://w3c.github.io/html-aam/#el-header.

[chris fleizach]

Comment on attachment 362886 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=362886&action=review

>> Source/WebCore/accessibility/AccessibilityRenderObject.cpp:2871
>> +        if (!isDescendantOfElementType({ articleTag, sectionTag, mainTag, blockquoteTag, detailsTag, fieldsetTag, figureTag, tdTag }))
> 
> BTW (for a new/separate bug): Headers fall into the very same mapping pattern. See https://w3c.github.io/html-aam/#el-header-ancestorbody versus https://w3c.github.io/html-aam/#el-header.

https://bugs.webkit.org/show_bug.cgi?id=195010

[WebKit Commit Bot]

Comment on attachment 362886 [details]
patch

Clearing flags on attachment: 362886

Committed r242051: <https://trac.webkit.org/changeset/242051>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Scott]

Just wanted to check in real quick to verify when this bug fix will be live?

Checking this bug today in Safari 12.1 on macOS Mojave 10.14.4 with this test file: https://scottaohara.github.io/testing/contentinfo/

No contentinfo landmarks are exposed.

Thank you.

[Ryosuke Niwa]

(In reply to Scott from comment #25)
> Just wanted to check in real quick to verify when this bug fix will be live?
> 
> Checking this bug today in Safari 12.1 on macOS Mojave 10.14.4 with this
> test file: https://scottaohara.github.io/testing/contentinfo/

Apple generally doesn't comment on when a particular bug fix will be included in our product.

Having said that, Safari Technology Preview is usually a good indicator of what features and bug fixes may be included in the future versions of Safari in macOS and iOS, and Safari Technology Preview 77 includes this fix:
https://webkit.org/blog/8658/release-notes-for-safari-technology-preview-77/

Note that it's not atypical for a given WebKit fix not to be included in the next minor update since "trunk" or the latest versions of WebKit have been historically only introduced in a new major OS (e.g. iOS 12.0), or in "E" (e.g. iOS 12.2) variants of releases that have historically happened around March.

[Scott]

good to know.  appreciate the response!

[Tyler Wilcock]

> Joanmarie's read on this is correct.
> 
> Footer should be promoted to a landmark and announced as contentinfo when
> scoped to the body element.
> 
> It should not be a landmark/announced as contentinfo if an ancestor of:
> a main element, or sectioning elements such as: article, aside, nav, or
> section.
> Nor should a footer be announced as contentinfo if an ancestor of a
> sectioning root element: blockquote, details, dialog, fieldset, figure, or
> td.
> 
> I'll provide a test case within the next few days if still necessary.
Hey Scott. I'm revisiting this logic as part of el-footer and el-header WPTs at:

https://wpt.fyi/results/html-aam/roles-contextual.html

You said:

> Nor should a footer be announced as contentinfo if an ancestor of a sectioning root element: blockquote, details, dialog, fieldset, figure, or td
Is this specced somewhere? I may just be missing it, but I only see mention of these two categories:

https://w3c.github.io/html-aam/#el-footer-ancestorbody
https://w3c.github.io/html-aam/#el-footer

The former is for footers scoped to a body, while the latter applies for footers scoped to a main element, or a "sectioning content element", which is currently defined as: article, aside, nav, section

I don't see any mention of "sectioning root elements". Is this defined elsewhere, or implicit somehow? WebKit implements it as you have written (minus the dialog element), but I'd either like to make WebKit match the spec, or update the spec to be comprehensive (if it isn't already).