WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
Bug 146930
AX: HTML native elements (header, footer, main, aside, nav) should work the same as ARIA landmarks, sometimes they don't
https://bugs.webkit.org/show_bug.cgi?id=146930
Summary
AX: HTML native elements (header, footer, main, aside, nav) should work the ...
Steve Faulkner
Reported
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.
Attachments
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2015-07-14 05:00:55 PDT
<
rdar://problem/21812293
>
Radar WebKit Bug Importer
Comment 2
2015-07-14 05:02:05 PDT
<
rdar://problem/21812303
>
Carolyn MacLeod
Comment 3
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
Scott
Comment 4
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
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug