Closed Bug 610650 Opened 14 years ago Closed 13 years ago

Change implementation of HTML5 landmark elements to conform to implementor guidelines

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla7

People

(Reporter: MarcoZ, Assigned: davidb)

References

(Blocks 1 open bug)

Details

(Keywords: meta)

Attachments

(1 file, 1 obsolete file)

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
OK I was going to reopen that bug, but this works too. Thanks for filing.
Assignee: nobody → bolterbugz
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?
(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. :)
(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.
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.
(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?
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.
(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.
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"
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.
"throw" sigh.
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.
(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.
(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.
(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 :)
(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.
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?
>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.
(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' :)
(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?
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
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.
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'"
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.
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.
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.
Attaching the changes I made for Steve.
Note to self: probably need to add back footer->contentinfo mapping.
(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 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.
Attachment #516252 - Flags: feedback?(marco.zehe)
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.
Attachment #516252 - Flags: feedback?(marco.zehe) → feedback+
Attached patch patchSplinter Review
Attachment #516252 - Attachment is obsolete: true
Attachment #543921 - Flags: review?(marco.zehe)
Attachment #543921 - Flags: review?(marco.zehe) → review+
Did this last patch ever land?
It was http://hg.mozilla.org/mozilla-central/rev/2d0037330eaf
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
You need to log in before you can comment on or make changes to this bug.