Last Comment Bug 610650 - Change implementation of HTML5 landmark elements to conform to implementor guidelines
: Change implementation of HTML5 landmark elements to conform to implementor gu...
Status: RESOLVED FIXED
: meta
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: mozilla7
Assigned To: David Bolter [:davidb]
:
:
Mentors:
Depends on:
Blocks: html5a11y
  Show dependency treegraph
 
Reported: 2010-11-09 05:37 PST by Marco Zehe (:MarcoZ)
Modified: 2011-11-01 08:18 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
WIP (not finished - requires endless debate) (3.77 KB, patch)
2011-03-02 06:30 PST, David Bolter [:davidb]
mzehe: feedback+
Details | Diff | Splinter Review
patch (3.89 KB, patch)
2011-07-05 06:27 PDT, David Bolter [:davidb]
mzehe: review+
Details | Diff | Splinter Review

Description Marco Zehe (:MarcoZ) 2010-11-09 05:37:12 PST
After bug 593368, we received feedback that this implementation does not conform to the specification for implementors the HTML5 WG and accessibility task force intended. The HTML5 accessibility taskforce version is here: http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html
The current HTML5 spec is here: http://dev.w3.org/html5/spec/content-models.html#annotations-for-assistive-technology-products-aria
Comment 1 David Bolter [:davidb] 2010-11-09 05:39:41 PST
OK I was going to reopen that bug, but this works too. Thanks for filing.
Comment 2 steve faulkner 2010-11-09 06:02:37 PST
Is it practical/possible to implement header/banner footer/contentinfo as per spec?

i.e. map the first header element in the DOM to banner and the last footer element in the DOM to contentinfo?
Comment 3 Marco Zehe (:MarcoZ) 2010-11-09 06:13:20 PST
(In reply to comment #2)
> Is it practical/possible to implement header/banner footer/contentinfo as per
> spec?
> 
> i.e. map the first header element in the DOM to banner and the last footer
> element in the DOM to contentinfo?

Reflexively, I would say that this is quite costly to calculate. But I would let Surkov and David answer to that in definite terms. :)
Comment 4 alexander :surkov 2010-11-09 06:30:49 PST
(In reply to comment #3)

> Reflexively, I would say that this is quite costly to calculate. But I would
> let Surkov and David answer to that in definite terms. :)

We could store them on document accessible object. I would work on this but I won't until this is blocking or Firefox 4 is released.
Comment 5 Marco Zehe (:MarcoZ) 2010-11-09 06:32:53 PST
On to the current mappings: Steve, at http://dev.w3.org/html5/html-api-map/overview.html, I notice that header and footer are currently not mapped to any role in MSAA/IA2, ATK, UIA etc. MSAA and ATK provide header and footer roles. We implement those currently in the nightly builds. These correspond to a header or footer section of a piece of apper, for example. The example you gave on my blog, http://www.brucelawson.co.uk/, seems to confirm that this is, transferred to the web and a single article, a useful mapping.

article: The spec suggestion does sound sensible, exposing it as a document with read-only state.

aside: Davidb, we need to expose this as IA"_ROLE_NOTE. There doesn't seem to be an ATK equivalent right now.
Comment 6 David Bolter [:davidb] 2010-11-09 06:41:31 PST
(In reply to comment #2)
> Is it practical/possible to implement header/banner footer/contentinfo as per
> spec?
> 
> i.e. map the first header element in the DOM to banner and the last footer
> element in the DOM to contentinfo?

Doesn't this seem a bit hacky?
Comment 7 steve faulkner 2010-11-09 06:48:34 PST
marco wrote:
"I notice that header and
footer are currently not mapped to any role in MSAA/IA2, ATK, UIA etc."

This is because we have not had chance to add this info yet, thanks for the pointer.

I would agree that using these to map to the HTML5 header and footer elements appears to be a good idea.
Comment 8 David Bolter [:davidb] 2010-11-19 07:52:13 PST
(In reply to comment #5)

> article: The spec suggestion does sound sensible, exposing it as a document
> with read-only state.

I'll look into this thanks.

> aside: Davidb, we need to expose this as IA"_ROLE_NOTE. There doesn't seem to
> be an ATK equivalent right now.

Note this has happened on bug 610362.
Comment 9 David Bolter [:davidb] 2011-02-24 07:15:50 PST
OK Steve pinged me with remaining issues:
"the footer is mapped to content info should not be, header is mapped to banner should not be, aside is mapped to note although would be better to be mapped to complimentary"
Comment 10 David Bolter [:davidb] 2011-02-24 08:07:02 PST
I know Jamie is not keen on looking for additional landmark roles, so I'll prep a try build and through it between him and Steve, in the octagon. Whoever emerges victorious can decide the fate of the patch.
Comment 11 David Bolter [:davidb] 2011-02-24 08:26:31 PST
"throw" sigh.
Comment 12 David Bolter [:davidb] 2011-02-24 11:09:48 PST
Try build should show up here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dbolter@mozilla.com-77aec6e4e5e5
Comment 13 steve faulkner 2011-02-25 03:50:45 PST
tried out the build, header and footer  are no longer picked up as banner/content info landmarks which is great!
looking via accprobe xml-role:footer for the footer element and xml-role:header for the header element have been added, where does the definition for these come from?
aside element has been mapped to complementary (good) tried with NVDA and this gets picked up as a landmark no problem! 

article has not been mapped to ARIA article as yet? Note it is not a landmark anyway, but be good to discuss how/if header, footer, article should be made available to end users. I question the utility of header/footer for end users due to the way they are specified in HTML5. I can see article may be useful, but header will almost always will contain a heading (h1-h6) as its primary content so the header semantic is redundant as users can already navigate via headings.
Comment 14 Marco Zehe (:MarcoZ) 2011-02-25 04:36:23 PST
(In reply to comment #13)
> article has not been mapped to ARIA article as yet? Note it is not a landmark
> anyway, but be good to discuss how/if header, footer, article should be made
> available to end users.

In our ARIA Map, "article" is mapped to a document accessible that has the READONLY state set:
http://mxr.mozilla.org/mozilla-central/source/accessible/src/base/nsARIAMap.cpp#93

David, what's the status of implementing this in the same way for the article element? I remember we discussed this a while back and agreed that this would make sense.
Comment 15 David Bolter [:davidb] 2011-02-25 07:01:37 PST
(In reply to comment #13)
> tried out the build, header and footer  are no longer picked up as
> banner/content info landmarks which is great!
> looking via accprobe xml-role:footer for the footer element and xml-role:header
> for the header element have been added, where does the definition for these
> come from?

I just followed http://dev.w3.org/html5/html-api-map/overview.html without cross referencing anything else.
Comment 16 David Bolter [:davidb] 2011-02-25 07:05:17 PST
(In reply to comment #14)
> (In reply to comment #13)
> In our ARIA Map, "article" is mapped to a document accessible that has the
> READONLY state set:
> http://mxr.mozilla.org/mozilla-central/source/accessible/src/base/nsARIAMap.cpp#93
> 
> David, what's the status of implementing this in the same way for the article
> element? I remember we discussed this a while back and agreed that this would
> make sense.

Status: it is implemented the same way :)
Comment 17 steve faulkner 2011-02-25 07:33:34 PST
(In reply to comment #15)
> (In reply to comment #13)
> > tried out the build, header and footer  are no longer picked up as
> > banner/content info landmarks which is great!
> > looking via accprobe xml-role:footer for the footer element and xml-role:header
> > for the header element have been added, where does the definition for these
> > come from?
> 
> I just followed http://dev.w3.org/html5/html-api-map/overview.html without
> cross referencing anything else.

OK so the current set of xml-roles is here http://www.w3.org/1999/xhtml/vocab/#XHTMLRoleVocabulary
which includes all ARIA roles.

they do not include header/footer, the inclusion of new roles is up for discussion for inclsuion in ARIA 1.1 / 2. What is the usefulness of having it declared as an object attribute xml-role:foo rather than just TAG:foo or role:foo ? One thing i can think of is that it differentiates it from the TAG:foo (s) that are not of use to AT.
Comment 18 David Bolter [:davidb] 2011-02-25 07:49:37 PST
Think of tag is raw data, namely the element name.
xml-roles is supposed to be raw data (namely the value of the role attribute), but is now re-purposed for html5 landmark elements (which I actually pushed back against).

AT want to look in one place for landmark info. Currently that place is xml-roles.

Do you guys agree I should just remove the addition of *any* xml-roles for html5 header and footer?
Comment 19 steve faulkner 2011-02-25 08:49:52 PST
>Do you guys agree I should just remove the addition of *any* xml-roles for
>html5 header and footer?

As we have discussed off list, I am not convinced of the benefits of header/footer being landmark roles as can be used to frequently in a document to provide the benefit of a landmark.

for example this is what is reported by NVDA with the current beta 11b, which has header/footer mapped to banner/content info:

Landmarks on the home page of bruce lawsons site (http://www.brucelawson.co.uk/):

    * banner role="banner"
    * complementary role="complementary"
    * search role="search"
    * banner header
    * content info footer
    * banner header
    * content info footer
    * banner header
    * content info footer
    * banner header
    * content info footer
    * banner header
    * content info footer
    * banner header
    * content info footer
    * banner header
    * content info footer
    * banner header
    * content info footer
    * banner header
    * content info footer
    * banner header
    * content info footer
    * navigation role="navigation"
    * content info role="contentinfo"

the upshot of this is that due to the way header/footer are specced they can and do appear multiple times on a page of sites that use them. i think that it is clear that the inclusion of header/footer as landmarks is of limited utility due to the frequency of their presence. the header also duplicates the navigation/identification utility of H1-h6 elements.
Comment 20 David Bolter [:davidb] 2011-02-25 08:54:11 PST
(In reply to comment #19)
> >Do you guys agree I should just remove the addition of *any* xml-roles for
> >html5 header and footer?
> 
> As we have discussed off list, I am not convinced of the benefits of
> header/footer being landmark roles as can be used to frequently in a document
> to provide the benefit of a landmark.

I'll take that as a 'yes' :)
Comment 21 David Bolter [:davidb] 2011-02-25 09:05:52 PST
(In reply to comment #19)
> Landmarks on the home page of bruce lawsons site
> (http://www.brucelawson.co.uk/):

You know... it isn't clear to me that the footer landmark is not useful here, but I'm not a proper user. Marco do you have thoughts here?
Comment 22 steve faulkner 2011-02-25 09:13:02 PST
what would be useful is to get some feedback from users my think is that having the word footer repeated multiple times with no context or differentiating information would not be useful,
I imageine it may be useful in combination with headings:
heading level 1 the beauty of feet
footer
heading level 2 smell the beauty
footer
Comment 23 Marco Zehe (:MarcoZ) 2011-02-26 10:20:47 PST
Well, header indeed doesn't make sense to have as a landmark, since there is always an h1 through h6 that the user can jump to. As for footer, at least on Bruce Lawson's page, it gives the semantic info about what categories the post was posted in etc. So useful information one *might* want to get to quickly. So footer is definitely more useful than header, and contentinfo *is*, in my opinion, the appropriate mapping here. At least when it comes to Bruce's example page, it's a perfect example of that. Because this is the content info for each blog post.
Comment 24 steve faulkner 2011-02-26 11:44:28 PST
hi Marco, 
I do agree that footer should be exposed, but not as a landmark.
Keep in mind I am not saying that footer should not be available as a navigable element, I am saying that it should not be included as a landmark. Currently JAWS for example, provides navigation features to a range of HTML structural features features such as lists (un-ordered, ordered, definition), headings, blockquotes, paragraphs, divs and others. None of these are included as landmarks. I consider the addition of elements that are likely to occur frequently on a page dilutes and overloads the "landmark" concept. Making it less useful. 
I think an example definition of landmark helps clarify what I mean:
"the position of a prominent or well-known object in a particular landscape; 'the church steeple provided a convenient landmark'"
Comment 25 Marco Zehe (:MarcoZ) 2011-02-26 23:15:29 PST
The problem, at least with JAWS, is that they are running out of letters. ;-) Other screen readers don't have this extensive a list of navigable objects. And I, having been a JAWS user myself for a long time, found that I didn't use 85% of these at all for my navigation. For example navigating to divs is totally pointless, IMO.

For NVDA, I could well imagine an addition to the Object list (NVDA+F7). Currently it allows for links, headings and landmarks, and it could get a fourth item type "interesting spots", and that could include footers, if we agree that footer is not a landmark.
Comment 26 steve faulkner 2011-02-27 02:03:08 PST
hi marco, 
"I didn't use 85% of these at all for my navigation. For example navigating to divs is totally pointless, IMO."

That is no surprise to me, i always wondered why that was there :-)

How about an addition to the object list that covers a useful subset of HTML sectioning elements that are either not already exposed (nav and aside are landmarks, headings are already exposed) or are not useful (header we agree is not useful as it replicates headings, hgroup is under a cloud and may be reomoved, its semantics are not clear), which leaves:
* section
* article
* footer
* blockquote

I am unsure about how firiefx uses "xml-role:" prefix to denote landmarks as an object attribute.

Is it possible/useful to have a prefix based on the categorisation in ARIA and HTML?

for example:
* landmark-role: for landmarks
* widget-role: for widgets:
* sectioning-role: for html5 sectioning elements

would this be a useful/usable categerisation for screen reading sofware implementors? it would need to be specced out though.
Comment 27 James Teh [:Jamie] 2011-02-27 15:38:08 PST
I'm not happy with the idea of adding new types to NVDA's Element List/Quick Navigation unless they are particularly useful. They also cannot be HTML specific. "Interesting spots" just sounds like another name for "landmark" to me. Contentinfo really does seem to make sense for footer. I guess I do follow the argument about diluting the usefulness of landmarks, though.

I tend to see article and section as one and the same as far as usefulness in navigation. Similarly, it might be useful to have a way to jump to content info such as footer. The problem is that, particularly in HTML4, people are probably already using the contentinfo landmark for this purpose, so it's already a landmark for the majority of sites.
Comment 28 David Bolter [:davidb] 2011-03-02 06:30:22 PST
Created attachment 516252 [details] [diff] [review]
WIP (not finished - requires endless debate)

Attaching the changes I made for Steve.
Comment 29 David Bolter [:davidb] 2011-03-02 06:31:39 PST
Note to self: probably need to add back footer->contentinfo mapping.
Comment 30 steve faulkner 2011-03-03 14:06:37 PST
(In reply to comment #29)
> Note to self: probably need to add back footer->contentinfo mapping.

hi dave, have been thinking about header/footer: is it practical to map header to banner and footer to contentinfo ONLY if they are not children of a HTML5 section or article element? If they are not children of these elements they will be being used as the main header/footer for a page and the mapping would be correct.
Comment 31 David Bolter [:davidb] 2011-06-26 18:18:42 PDT
Comment on attachment 516252 [details] [diff] [review]
WIP (not finished - requires endless debate)

Marco, what is your latest thinking? The twitterers want this change I think.
Comment 32 Marco Zehe (:MarcoZ) 2011-06-27 07:40:12 PDT
Comment on attachment 516252 [details] [diff] [review]
WIP (not finished - requires endless debate)

Hm, I can go with the header change, but still agree that footer is contentinfo.

And that brings me to this: In the code part, you leave

>   else if (mContent->Tag() == nsAccessibilityAtoms::footer) 
>     nsAccUtils::SetAccAttr(aAttributes, nsAccessibilityAtoms::xmlroles,
>                            NS_LITERAL_STRING("contentinfo"));

as is, but in the tests, you change:

>-      testAttrs("footer", {"xml-roles" : "contentinfo"}, true);
...
>+      testAttrs("footer", {"xml-roles" : ""}, true);

I'm giving you an f+ based on the header xml role removal, but sincerely hope that footer will remain as is since this really makes sense, IMO.
Comment 33 David Bolter [:davidb] 2011-07-05 06:27:20 PDT
Created attachment 543921 [details] [diff] [review]
patch
Comment 34 Marco Zehe (:MarcoZ) 2011-11-01 05:51:38 PDT
Did this last patch ever land?
Comment 35 alexander :surkov 2011-11-01 06:00:41 PDT
It was http://hg.mozilla.org/mozilla-central/rev/2d0037330eaf

Note You need to log in before you can comment on or make changes to this bug.