Bug 146930

Summary: AX: HTML native elements (header, footer, main, aside, nav) should work the same as ARIA landmarks, sometimes they don't
Product: WebKit Reporter: Steve Faulkner <faulkner.steve>
Component: AccessibilityAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: carolynmacleod4, Carolyn_MacLeod, faulkner.steve, jcraig, mike, scottaohara, webkit-bug-importer, webkit
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 172817    

Description Steve Faulkner 2015-07-14 05:00:34 PDT
While Native HTML elements that map to ARIA landmark roles have the correct subrole mapping,  In VoiceOver only a subset of native landmark elements are included in the webrotor. 

Using this test page: https://rawgit.com/stevefaulkner/HTML5accessibility/master/tests/structural-elements.html


In latest Safari (8) only banner, complementary and navigation are recognised/listed in the landmarks rotor in VO.

In latest webkit (Version 8.0.6 (10600.6.3, r186796)) banner, complementary main and navigation are listed in the landmarks rotor in VO.

footer is listed in neither.

Note that when navigation through the content using VO, all the native elements are recognised as landmarks, its only in the rotor where the issue arises.

Meanwhile on this test page http://www.html5accessibility.com/tests/structure.html

In both latest safari and webkit:  banner, complementary main and navigation are listed in the landmarks rotor in VO.

footer is listed in neither.

Note that when navigation through the content using VO, all the native elements are recognised as landmarks, its only in the rotor where the issue arises.

I cannot find any difference in the acc tree in webkit/safari between elements with landmark roles explicitly added or native landmarks, apart from footer which has a different AXDescription: "footer" vs "content information", thus it is expected that VO will treat them the same as it only looks at the acc tree.
Comment 1 Radar WebKit Bug Importer 2015-07-14 05:00:55 PDT
<rdar://problem/21812293>
Comment 2 Radar WebKit Bug Importer 2015-07-14 05:02:05 PDT
<rdar://problem/21812303>
Comment 3 Carolyn MacLeod 2018-11-12 11:35:25 PST
Tried this again in Safari 11.1 and Chrome 70.0.3538.102
on macOS 10.13.6

In both browsers, VoiceOver reads the following HTML elements:
   header, nav, main, aside, section with label
   ... but not footer

Seems like it's a VoiceOver bug, because it happens in both browsers.
It's probably something super-simple to fix, because VO *does* recognize the contentinfo role. It's just not reading the footer element (which has an implicit role of contentinfo).

In case it's helpful, here's another good test page (click the "Show Landmarks" button for a nice overview of the page): http://w3c.github.io/aria-practices/examples/landmarks/index.html
Comment 4 Scott 2019-08-06 11:42:11 PDT
Here are some additional tests/results for header and footer elements:

https://scottaohara.github.io/tests/html-footer/contentinfo-landmark-tests.html
and
https://scottaohara.github.io/tests/html-header/banner-landmark-tests.html

Specific results for Webkit and footer elements:

Testing with macOS Safari Tech Preview Release 88 (Safari 13.0, WebKit 14608.1.36), three content information landmarks are exposed. 1 as a child of the nav element (incorrect), another as a child of dialog element (incorrect) and the last as it is correctly scoped to body element.

Testing with iOS 12.3.1 and VoiceOver, every footer is exposed as a "footer" landmark except for the footers within section and article elements.  Only the footer scoped to the body element should have been exposed as a contentinfo landmark.


Specific results for Webkit and header elements:
The following is the same result for Safari 12.1.1 on macOS and Safari on iOS 12.3.1:
Except for the header elements within section, and article elements all others (12) were exposed as banner landmarks, where the expectation was only the header scoped to body would be exposed as a banner landmark.

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