Bug 190138 - AX: <footer> HTML5 tag not reading as ARIA Landmark to VoiceOver
Summary: AX: <footer> HTML5 tag not reading as ARIA Landmark to VoiceOver
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: Other
Hardware: Macintosh macOS 10.14
: P2 Normal
Assignee: chris fleizach
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-10-01 07:04 PDT by Paul J. Adam
Modified: 2019-04-07 13:39 PDT (History)
13 users (show)

See Also:


Attachments
footer not shown in the VoiceOver Landmarks Rotor (370.42 KB, image/png)
2018-10-01 07:04 PDT, Paul J. Adam
no flags Details
patch (5.75 KB, patch)
2019-02-14 11:49 PST, chris fleizach
no flags Details | Formatted Diff | Diff
patch (19.20 KB, patch)
2019-02-23 09:57 PST, chris fleizach
ews: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ews101 for mac-highsierra (2.43 MB, application/zip)
2019-02-23 11:00 PST, Build Bot
no flags Details
Archive of layout-test-results from ews114 for mac-highsierra (2.05 MB, application/zip)
2019-02-23 11:43 PST, Build Bot
no flags Details
Archive of layout-test-results from ews126 for ios-simulator-wk2 (2.48 MB, application/zip)
2019-02-23 11:56 PST, Build Bot
no flags Details
patch (20.77 KB, patch)
2019-02-24 22:59 PST, chris fleizach
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Paul J. Adam 2018-10-01 07:04:18 PDT
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.
Comment 1 Radar WebKit Bug Importer 2018-10-01 07:05:15 PDT
<rdar://problem/44907695>
Comment 2 Scott 2019-02-14 05:54:44 PST
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.
Comment 3 chris fleizach 2019-02-14 08:54:03 PST
(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
Comment 4 chris fleizach 2019-02-14 11:49:48 PST
Created attachment 362043 [details]
patch
Comment 5 Joanmarie Diggs (irc: joanie) 2019-02-14 12:06:06 PST
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
Comment 6 chris fleizach 2019-02-14 12:11:19 PST
(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
Comment 7 Joanmarie Diggs (irc: joanie) 2019-02-14 14:37:56 PST
(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!
Comment 8 chris fleizach 2019-02-14 17:11:02 PST
(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!
Comment 9 Joanmarie Diggs (irc: joanie) 2019-02-14 18:11:36 PST
(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.
Comment 10 chris fleizach 2019-02-14 19:07:40 PST
(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?
Comment 11 Scott 2019-02-14 20:23:59 PST
(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.
Comment 12 chris fleizach 2019-02-23 09:57:26 PST
Created attachment 362827 [details]
patch

Updated patch
Comment 13 Build Bot 2019-02-23 11:00:37 PST
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
Comment 14 Build Bot 2019-02-23 11:00:38 PST
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
Comment 15 Build Bot 2019-02-23 11:43:03 PST
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
Comment 16 Build Bot 2019-02-23 11:43:05 PST
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
Comment 17 Build Bot 2019-02-23 11:56:43 PST
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
Comment 18 Build Bot 2019-02-23 11:56:45 PST
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
Comment 19 chris fleizach 2019-02-24 22:59:17 PST
Created attachment 362886 [details]
patch
Comment 20 chris fleizach 2019-02-25 10:33:26 PST
Comment on attachment 362886 [details]
patch

@Joanmarie are you able to review now?
Comment 21 Joanmarie Diggs (irc: joanie) 2019-02-25 10:52:27 PST
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.
Comment 22 chris fleizach 2019-02-25 11:05:48 PST
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
Comment 23 WebKit Commit Bot 2019-02-25 11:15:29 PST
Comment on attachment 362886 [details]
patch

Clearing flags on attachment: 362886

Committed r242051: <https://trac.webkit.org/changeset/242051>
Comment 24 WebKit Commit Bot 2019-02-25 11:15:30 PST
All reviewed patches have been landed.  Closing bug.
Comment 25 Scott 2019-04-05 05:56:49 PDT
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.
Comment 26 Ryosuke Niwa 2019-04-05 20:04:40 PDT
(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.
Comment 27 Scott 2019-04-06 05:30:57 PDT
good to know.  appreciate the response!