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 21866 - modify header and footer aria info
Summary: modify header and footer aria info
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: CR HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P3 normal
Target Milestone: ---
Assignee: Robin Berjon
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, aria
Depends on: 21164
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-29 12:34 UTC by steve faulkner
Modified: 2013-05-01 01:27 UTC (History)
6 users (show)

See Also:


Attachments

Description steve faulkner 2013-04-29 12:34:10 UTC
+++ This bug was initially created as a clone of Bug #21164 +++

modify the ARIA mapping info for header and footer to reflect the webkit implementation and expected Firefox implementation. After discussion with implementers it has been agreed that mapping header to banner and footer to contentinfo when not a child of an article or section element (as per webkit) is a good way to go. So reflect this in the ARIA mapping table in the spec: http://www.w3.org/html/wg/drafts/html/master/dom.html#wai-aria
Comment 1 steve faulkner 2013-04-29 12:38:02 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: (as part of addition of main to HTML5 CR) https://github.com/w3c/html/commit/f52f9d833d67440caadb6ac01f9c1861c33130d5

Rationale: Spec now reflects one implementations (webkit) +  (Firefox)
Comment 2 Ian 'Hixie' Hickson 2013-04-30 05:16:20 UTC
Why would you expose any role for <header>?
Comment 3 steve faulkner 2013-04-30 06:01:21 UTC
(In reply to comment #2)
> Why would you expose any role for <header>?

why would you not expose a role for <header>?
Comment 4 Ian 'Hixie' Hickson 2013-04-30 17:45:28 UTC
Same reason you wouldn't expose a role for <div> today. I don't understand. What does exposing a role for <header> do that's useful to the user?
Comment 5 steve faulkner 2013-04-30 17:57:06 UTC
(In reply to comment #4)
> Same reason you wouldn't expose a role for <div> today. I don't understand.
> What does exposing a role for <header> do that's useful to the user?

both header and footer act as landmarks when not in article or section elements. 
landmarks are used (primariy) by assistive technology users to navigate and understand global aspects of page content.
There is a helpful short video that explains the utility of landmark roles from a users perspective: http://www.youtube.com/watch?feature=player_embedded&v=IhWMou12_Vk#!
If you have any data or research to indicate that this mapping is not useful please provide it.
Comment 6 Ian 'Hixie' Hickson 2013-05-01 01:27:51 UTC
Blimey that's a terrible UI. You hit semicolon and the browser says "content info landmark"? I don't even know where to begin.

Anyway, ok, I suppose if we must use ARIA to get ATs to work, it makes sense to have them be marked up with landmark roles... but then why not in sections or articles? Why would landmark roles not be useful there too? Is it just that there are no suitable landmarks yet?