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: Did Not Understand Request
Change Description: no spec change
Rationale: I have no idea what this means. Isn't this what the whole spec does?

>I have no idea what this means. Isn't this what the whole spec does?

no.

but this document is a start: HTML to Platform Accessibility APIs
http://www.paciellogroup.com/blog/misc/HTML5/HTML-API-MAPPING.html

I really have no idea what problem this bug is reporting

(In reply to comment #3)
> I really have no idea what problem this bug is reporting

The current ARIA section of the spec defines a subset of normative requirments for mappings of HTML elements to accessibility APIs using ARIA roles as an intermediary. i don't think this is the best way to provide the mappings. The mappings should be provided in the form of the document i linked to.

Rather than restate the request endlessly I will leave it up to you to provide a counter to the change proposal.

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: Rejected
Change Description: no spec change
Rationale: Oh, this is just a request to change the editorial style to include things like accessibility API mappings? If so, then I strongly disagree that that makes sense. Just like we don't define default UI at the pixel level, we shouldn't define default UI at the Accessibility API level. Browsers should compete with each other to be more accessible.

I thought it was agreed in TPAC at Mandelieu that the mapping is a separate deliverable and isn't going to be included in the HTML5 spec proper. Even if the mapping spec were normative for a given snapshot of a particular accessibility API, it obviously can't cover subsequently introduced accessibility API (and probably wouldn't cover rare current APIs).

Now that I've read some tweets, I'd like to add the following for avoidance of doubt:
I think two browsers that expose content to the same accessibility API should expose the same piece of HTML in the same way which should be the most accurate way permitted by that API.

(In reply to comment #6)
> I thought it was agreed in TPAC at Mandelieu that the mapping is a separate
> deliverable and isn't going to be included in the HTML5 spec proper. Even if
> the mapping spec were normative for a given snapshot of a particular
> accessibility API, it obviously can't cover subsequently introduced
> accessibility API (and probably wouldn't cover rare current APIs).

I don't have a problem with the mapping tables being informative, It could bebe an in the main spec or an appendix or a seperate document referenced from the html5 spec.  But then the normative implementation statements in regards to ARIA must be removed from the HTML5 spec as they are mandating accessibility API mappings by proxy.
see the stuff about mapping <img> to image/graphic roles in accessibility APIs as an example (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10481)

(In reply to comment #8)
> But then the normative implementation statements in regards to
> ARIA must be removed from the HTML5 spec as they are mandating accessibility
> API mappings by proxy.

The whole point of implementation statement by reference to ARIA is to say that certain things must map the same way as certain ARIA things without having to say what that way is in terms of any concrete platform API.

I think saying that something has to map the same way as something else is completely compatible with externalizing what the concrete mapping is.

(In reply to comment #9)
> (In reply to comment #8)
> > But then the normative implementation statements in regards to
> > ARIA must be removed from the HTML5 spec as they are mandating accessibility
> > API mappings by proxy.
> The whole point of implementation statement by reference to ARIA is to say that
> certain things must map the same way as certain ARIA things without having to
> say what that way is in terms of any concrete platform API.
> I think saying that something has to map the same way as something else is
> completely compatible with externalizing what the concrete mapping is.



The main issue with this is that the mappings are incomplete, many elements in the ARIA section have no default roles,state or properties. Accessibility APIs have role states and properties not included in ARIA. How ARIA should map to accessibility APIs is in the ARIA implememntation guide. How HTML5 should map to  accessibility APIs should be in a HTML5 to accessibility API implementation guide.

(In reply to comment #10)
> The main issue with this is that the mappings are incomplete, many elements in
> the ARIA section have no default roles,state or properties. Accessibility APIs
> have role states and properties not included in ARIA. How ARIA should map to
> accessibility APIs is in the ARIA implememntation guide. How HTML5 should map
> to  accessibility APIs should be in a HTML5 to accessibility API implementation
> guide.

I think it's still appropriate for HTML5 to say that foo in HTML5 has to be mapped to the same accessible role as ARIA role bar even we want there to be an ARIA to accessibility API spec and an HTML to accessibility API spec.

Or do you want some HTML stuff to use accessibility API roles that are more refined than what ARIA maps to?

(In reply to comment #11)
> (In reply to comment #10)
> > The main issue with this is that the mappings are incomplete, many elements in
> > the ARIA section have no default roles,state or properties. Accessibility APIs
> > have role states and properties not included in ARIA. How ARIA should map to
> > accessibility APIs is in the ARIA implememntation guide. How HTML5 should map
> > to  accessibility APIs should be in a HTML5 to accessibility API implementation
> > guide.
> 
> I think it's still appropriate for HTML5 to say that foo in HTML5 has to be
> mapped to the same accessible role as ARIA role bar even we want there to be an
> ARIA to accessibility API spec and an HTML to accessibility API spec.
> 
> Or do you want some HTML stuff to use accessibility API roles that are more
> refined than what ARIA maps to?


Note that the spec gives license to use a more refined accessibility API role when available and appropriate:

"User agents may apply different defaults than those described in this section in order to expose the semantics of HTML elements in a manner more fine-grained than possible with the above definitions."

Saying element foo has a default role of bar just means that <foo> and <foo role=bar> should behave the same, but this can use more specific accessibility API mappings than role bar would generally use, if appropriate for that element. I'm not sure what it would mean to say <foo> has a default role of bar if that were not the case. In fact, I believe this conclusion follows from ARIA without the specific requirements of the HTML5 spec, so long as any elements have a default role specified. Thus, I believe the only way to really do what this bug is asking is to remove all default roles.

At least that is my understanding.

(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > The main issue with this is that the mappings are incomplete, many elements in
> > > the ARIA section have no default roles,state or properties. Accessibility APIs
> > > have role states and properties not included in ARIA. How ARIA should map to
> > > accessibility APIs is in the ARIA implememntation guide. How HTML5 should map
> > > to  accessibility APIs should be in a HTML5 to accessibility API implementation
> > > guide.
> > 
> > I think it's still appropriate for HTML5 to say that foo in HTML5 has to be
> > mapped to the same accessible role as ARIA role bar even we want there to be an
> > ARIA to accessibility API spec and an HTML to accessibility API spec.
> > 
> > Or do you want some HTML stuff to use accessibility API roles that are more
> > refined than what ARIA maps to?
> Note that the spec gives license to use a more refined accessibility API role
> when available and appropriate:
> "User agents may apply different defaults than those described in this section
> in order to expose the semantics of HTML elements in a manner more fine-grained
> than possible with the above definitions."
> Saying element foo has a default role of bar just means that <foo> and <foo
> role=bar> should behave the same, but this can use more specific accessibility
> API mappings than role bar would generally use, if appropriate for that
> element. I'm not sure what it would mean to say <foo> has a default role of bar
> if that were not the case. In fact, I believe this conclusion follows from ARIA
> without the specific requirements of the HTML5 spec, so long as any elements
> have a default role specified. Thus, I believe the only way to really do what
> this bug is asking is to remove all default roles.
> At least that is my understanding.

OK, so some questions:

1. where there is a strong semantic of 'no role' what are implementors supposed to do, is that clear? because its not to me.
2. if the default roles are kept in as is would it not be best to also provide implementors with a clear reference from this section to a more comprehensive html5 to accessibility API mapping document?

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: Rejected
Change Description: no spec change
Rationale: What the HTML spec is doing here is what the WAI requested we do. If you disagree, then please escalate this.

Bug triage sub-team this this is not a HTML A11Y TF priority. Integration of the HTML to AAPI mapping is important but don't need TF review of the specific mechanism via a bug. Assigning to Steve Faulkner, who may either close based on that recommendation, or escalate it.

To make the bug complete, it relates to http://dev.w3.org/html5/html-api-map/overview.html. This version supplants an earlier draft of the same document that was referenced in comment 2.

Issue 161:  http://www.w3.org/html/wg/tracker/issues/161