This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27961 - <footer> should map to the ARIA role contentinfo
Summary: <footer> should map to the ARIA role contentinfo
Status: RESOLVED FIXED
Alias: None
Product: ARIA
Classification: Unclassified
Component: HTML AAM (show other bugs)
Version: 1.1
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Jason Kiss
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-04 22:22 UTC by Dominic Mazzoni
Modified: 2015-06-24 04:23 UTC (History)
6 users (show)

See Also:


Attachments

Description Dominic Mazzoni 2015-02-04 22:22:14 UTC
Reported by aboxhall@google.com:

<footer> is specced as having no related ARIA role, but exposes xml-roles:contentinfo, strongly suggesting it should be ARIA role contentinfo
Comment 1 steve faulkner 2015-02-04 22:34:55 UTC
(In reply to Dominic Mazzoni from comment #0)
> Reported by aboxhall@google.com:
> 
> <footer> is specced as having no related ARIA role, but exposes
> xml-roles:contentinfo, strongly suggesting it should be ARIA role contentinfo

Unclear what you mean? 'xml-roles:contentinfo' is the related ARIA role.
Comment 2 Jason Kiss 2015-06-03 05:30:45 UTC
(In reply to steve faulkner from comment #1)
> (In reply to Dominic Mazzoni from comment #0)
> > Reported by aboxhall@google.com:
> > 
> > <footer> is specced as having no related ARIA role, but exposes
> > xml-roles:contentinfo, strongly suggesting it should be ARIA role contentinfo
> 
> Unclear what you mean? 'xml-roles:contentinfo' is the related ARIA role.

The mapping for <footer> has "No corresponding role" under WAI-ARIA [1]. I think Dominic and Alice are suggesting it should specify "contentinfo" as the corresponding role. 

The corresponding role for <footer> is "contentinfo" in the case that the <footer> is not a descendant of an <article> or <section> element. However, the api mapping for a <footer> whose nearest ancestor is the <body> element and so whose role is "contentinfo" doesn't necessarily match the mapping for the "contentinfo" role as expressed in CORE-AAM [2]. At least this is the case with the AXAPI mapping, where the AXRoleDescription for a <footer> that is a "contentinfo" landmark is "footer", while the default AXRoleDescription for a "contentinfo" landmark is just "content".

I wonder if we should have two entries for <footer> distinguished by their nearest sectioning ancestor, i.e. "footer (contained by article or section)" and "footer (not contained by article or section)", and describe the mappings accordingly. In the case of the footer not contained by article or section elements, we could identify "contentinfo" as the corresponding role.

But thinking this through has raised a few other questions for me:

A. The entry for <footer> in the HTML5.1 spec [3] makes <footer> valid in <aside> and <nav> sectioning elements, as well sectioning roots, i.e. <blockquote>, <body>, <details>, <dialog>, <fieldset>, <figure>, and <td>. Surely this is the same scenario as <footer> in <article> or <section>, namely it does not represent an ARIA "contentinfo" landmark, and in which case the a11y mapping needs to make this clear? So now we need to distinguish between "footer (nearest sectioning element ancestor is body)", in which case it has a "contentinfo" role, and "footer (nearest sectioning element ancestor is not body)" where it has no default ARIA role. I'll file a separate bug for this.

B. The <header> element [4] and "banner" role [5] are in a similar boat, so whatever approach we take for <footer>, we need to do the same for <header>.

C. The current IA2 and ATK mappings for <footer> is ROLE_FOOTER. For IA2 [6] this makes it "Footer of a document page", and for ATK [7], "An object that serves as a document footer". This makes sense if the <footer>'s nearest ancestor is the <body> element in which case it is a footer for the page. But it doesn't sound right if the nearest ancestor is an <article> or <section> or <blockquote> or <td>, as these are not documents in themselves. I'll file a separate bug for this.

[1] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-footer
[2] http://w3c.github.io/aria/core-aam/core-aam.html#role-map-contentinfo
[3] http://www.w3.org/TR/html51/semantics.html#the-footer-element
[4] http://www.w3.org/TR/html51/semantics.html#the-header-element
[5] http://w3c.github.io/aria/core-aam/core-aam.html#role-map-banner
[6] http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_accessible_role_8idl.html#ae37ff81431ee3762a5d41a2cb909108da6e45e9d06ef0d62ebdabaab430f2ae13
[7] https://developer.gnome.org/atk/stable/AtkObject.html#AtkRole
Comment 3 Jason Kiss 2015-06-16 03:21:20 UTC
I've updated footer [1] and header [2] mappings.

There are now two entries for each: one entry is for the scenario where the element's nearest ancestor sectioning content or sectioning root element is the body element (in which case it applies to the page as a whole and is a landmark), and one for where it is not. 

The UIA Express and UIA mappings were updated to align more with the CORE-AAM mappings for banner and contentinfo roles.

The IA2 mapping for footer/header when they don't apply to the page or document, i.e., when they are descendants of some sectioning element other than body, were updated to use the more generic ROLE_SECTION. 

Only when the nearest ancestor sectioning element is body do IA2 and ATK get the more specific ROLE_HEADER and ROLE_FOOTER. (ATK does have ROLE_LANDMARK: would this be the better role in this scenario? I've filed a bug with IA2 to also create ROLE_LANDMARK [3].)

[1] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-footer
[2] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-header
[3] https://bugs.linuxfoundation.org/show_bug.cgi?id=1293
Comment 4 Jason Kiss 2015-06-24 04:23:06 UTC
Closing as I think this has been resolved with https://github.com/w3c/aria/commit/75965533b2b865f9cf94a0b4063fd265d0be0e64

Reopen if any concerns.