Closed
Bug 1252799
Opened 8 years ago
Closed 6 years ago
header/footer should only map to banner/contentinfo when not child of sectioning content or main
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
RESOLVED
DUPLICATE
of bug 1316285
People
(Reporter: faulkner.steve, Assigned: MarcoZ, Mentored)
Details
Attachments
(1 obsolete file)
Currently in Firefox, header and footer are exposed as banner/contentinfo landmarks unless contained with section or article elements, we think this is too broad and these roles should only exposed if not a child of any sectioning content or main elements the acc API mappings for the elements reflect this stricter definition: API mapping for header and footer http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-header http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-footer
Assignee | ||
Updated•8 years ago
|
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
Version: unspecified → Trunk
Comment 1•8 years ago
|
||
> these roles should only exposed if not a child of any sectioning content or main elements
Just stressing that it's descendant, not child. For instance:
<article><header>Not a banner landmark</header></article>
<article><div><div><header>Still not a banner landmark</header></div></div></article>
Assignee | ||
Comment 2•8 years ago
|
||
Added the elements in the order "sectioning elements", "sectioning roots", then main. That's why they're not in strict alphabetical order.
Assignee: nobody → mzehe
Status: NEW → ASSIGNED
Attachment #8725665 -
Flags: review?(surkov.alexander)
Reporter | ||
Comment 3•8 years ago
|
||
> Just stressing that it's descendant, not child.
yeah thanks, and sorry for my unclear use of the terminology.
Comment 4•8 years ago
|
||
Am I right that we want to implement this wording of the spec "foot (nearest ancestor sectioning content or sectioning root element is body)". Could you please give me couple examples for that rule?
Comment 5•7 years ago
|
||
oh shoot, two years old review request! Marco, could you please answer comment #4?
Flags: needinfo?(mzehe)
Assignee | ||
Comment 6•7 years ago
|
||
<body><header>this is banner</header></body> <body><div><header>This is still banner</header></div></body> <body><article><header>This is not banner</header></article></body>
Flags: needinfo?(mzehe)
Comment 7•6 years ago
|
||
Comment on attachment 8725665 [details] [diff] [review] Extend the forbidden ancestors for the XML role attribute creation Review of attachment 8725665 [details] [diff] [review]: ----------------------------------------------------------------- sorry, totally slept off my radar ::: accessible/generic/HyperTextAccessible.cpp @@ +1139,5 @@ > > if (mContent->IsAnyOfHTMLElements(nsGkAtoms::header, > nsGkAtoms::footer)) { > + // Only map header and footer if they are descendants of a body tag. > + // All other sectioning roots, sectioning elements, and the main element are excluded. I would keep the comment closer the spec wording, something like: Header/footer elements having a body as a sectioning root, i.e. not contained by blockquote, details, dialog, fieldset, figure or td elements, and not contained by main element or a sectioning content, such as article, aside, nav and section elements.
Attachment #8725665 -
Flags: review?(surkov.alexander) → review+
Assignee | ||
Comment 8•6 years ago
|
||
Comment on attachment 8725665 [details] [diff] [review] Extend the forbidden ancestors for the XML role attribute creation It turns out that this has been fixed for Firefox 57 in bug 1316285, and none of us remembered this two year old bug. Will dupe this to that other one. :)
Attachment #8725665 -
Attachment is obsolete: true
Assignee | ||
Updated•6 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Comment 10•6 years ago
|
||
(In reply to Marco Zehe (:MarcoZ) from comment #8) > Comment on attachment 8725665 [details] [diff] [review] > Extend the forbidden ancestors for the XML role attribute creation > > It turns out that this has been fixed for Firefox 57 in bug 1316285, and > none of us remembered this two year old bug. Will dupe this to that other > one. :) it seems bugzilla has a lot of out-dated surprises :)
You need to log in
before you can comment on or make changes to this bug.
Description
•