459395 - Expose landmarks object attribute

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, enhancement)

Description

[Aaron Leventhal]

This is still under discussion, but I'm beginning to like the idea:

Expose a landmarks object attribute that only includes the following roles:
["article", "banner", "complementary", "contentinfo", "definition",  "main", "note", "navigation", "region", "search", "status", "log", "menubar", "tree", "grid", "treegrid]

In addition, some HTML 5 tags should also be considered the equivalent. This means:
1) they must get an accessible object and 
2) if that role is not already in "landmarks" it must be appended

Comment 1

[Aaron Leventhal]

Here are the HTML 5 to landmarks mappings if we do this:

<article> to "article"
<aside> to "complementary" (or should it be "note")
<dfn> to "definition"
<iframe> to "region"
<nav> to "navigation"

I forgot these 2, but they should be included in the main list of landmarks:
"document" and "application" (especially when not at the root).

Don't forget that if the element uses the role attribute that overrides the semantics of the tag. So <iframe role="application"> should not be treated as "region".

Comment 2

[Aaron Leventhal]

I think HTML 5 <footer> should map to "contentinfo"

Comment 3

[Aaron Leventhal]

We should not expose this object attribute on the root accessible object for a web page (however for an iframe doc it's ok).

Comment 4

[Simon Pieters [:zcorpan]]

I think it's not appropriate to map <dfn> to "definition" since "definition" is the whole definition while <dfn> is just the defining *term*.

<p role=definition>A <dfn>foo</dfn> is blah blah blah.</p>

AIUI, anyway...

Comment 5

[Simon Pieters [:zcorpan]]

HTML5 says

"The dfn element represents the defining instance of a term. The paragraph, description list group, or section that is the nearest ancestor of the dfn element must also contain the definition(s) for the term given by the dfn element."

So it would be appropriate to expose the nearest paragraph, description list group, or section ancestor of the dfn element as "definition", but note that none of those necessarily represent an element in the DOM.

Comment 6

[Aaron Leventhal]

I worked hard to get a good list of landmarks from the PF group, but what it ended up as was spec writers deciding what users should want.

Which objects on a page should be navigated to as part of an AT landmark cycle is subjective. I said document and article should be, and the group said no.

In addition, the AT isn't likely to get this kind of object attribute from IE or WebKit any time soon. I think the AT simply needs to look at the roles on each object and search for an appropriate landmark, from its own list.

Comment 7

[Henri Sivonen (:hsivonen)]

I don't understand the wontfixing of this bug. It seems that JAWS 10 gets landmarks from Firefox somehow:
http://www.paciellogroup.com/blog/misc/landmarks.html

Shouldn't the corresponding HTML5 elements be exposed via the same mechanism--whatever it is?

Comment 8

[James Teh [:Jamie]]

(In reply to comment #7)
> It seems that JAWS 10 gets
> landmarks from Firefox somehow:
It probably uses the ARIA role attribute of DOM nodes or the xml-roles IAccessible2 object attribute.

> Shouldn't the corresponding HTML5 elements be exposed via the same
> mechanism--whatever it is?
Yes. However, imo, it doesn't make sense to expose defined HTML tags in xml-roles, so this existing mechanism probably won't work. Another mechanism will probably have to be introduced. Ugly.

Comment 9

[Henri Sivonen (:hsivonen)]

What's wrong with exposing native elements via xml-roles if that’s the receiver-supported API for exposing these semantics?

Comment 10

[James Teh [:Jamie]]

(In reply to comment #9)
> What's wrong with exposing native elements via xml-roles if that’s the
> receiver-supported API for exposing these semantics?
xml-roles is essentially just a copy of the ARIA role attribute. Doing as you suggest would involve tacking the HTML 5 tag name on to that list, which I guess is okay. However, some of the native HTML 5 structural elements have different names to the ARIA roles (e.g. nav instead of navigation), so you'd either need to map them to ARIA roles or ATS would have to map them.

It does concern me that the current method of exposing landmarks is so ARIA specific. The interface for accessing landmark information really should be uniform for ARIA and HTML 5. Accessibility APIs are supposed to abstract all of this somewhat.

Comment 11

[Henri Sivonen (:hsivonen)]

(In reply to comment #10)
> (In reply to comment #9)
> > What's wrong with exposing native elements via xml-roles if that’s the
> > receiver-supported API for exposing these semantics?
> xml-roles is essentially just a copy of the ARIA role attribute. Doing as you
> suggest would involve tacking the HTML 5 tag name on to that list, which I
> guess is okay. However, some of the native HTML 5 structural elements have
> different names to the ARIA roles (e.g. nav instead of navigation), so you'd
> either need to map them to ARIA roles or ATS would have to map them.

I think the browser should map them. The interface between the browser and the AT shouldn't have to care how the semantics came off the network--just what semantics are being communicated between the browser and the AT.

> It does concern me that the current method of exposing landmarks is so ARIA
> specific. The interface for accessing landmark information really should be
> uniform for ARIA and HTML 5. Accessibility APIs are supposed to abstract all of
> this somewhat.

I think mapping the HTML5 structural elements to the tokens in xml-roles that the AT support is the abstraction. It just happens for historical reasons that the tokens match role attribute values from ARIA.

This this bug be reopened now?

Comment 12

[alexander :surkov (:asurkov)]

Technically this bug is about to introduce new object attribute to expose subset of landmarks but PF group said it's not needed (comment #6). If you like to map some HTML elements to xml-roles attribute then it probably makes sense for some HTML elements. But it should be discussed in another bug I think.

Comment 13

[David Bolter [:davidb] (NeedInfo me for attention)]

Note bug 391829 was fixed... which might cover all the cases we care about.

Comment 14

[James Teh [:Jamie]]

(In reply to comment #13)
> Note bug 391829 was fixed... which might cover all the cases we care about.
Err... I don't follow how this is related. That bug relates to live regions. This one relates to landmarks.