- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Fri, 17 Oct 2014 10:24:40 -0500
- To: "White, Jason J" <jjwhite@ets.org>
- Cc: Chris Fleizach <cfleizach@apple.com>, David Bolter <dbolter@mozilla.com>, Dominic Mazzoni <dmazzoni@google.com>, James Craig <jcraig@apple.com>, PF <public-pfwg@w3.org>, "Alexander Surkov" <surkov.alexander@gmail.com>
- Message-ID: <OF6C67B2ED.01BD8C97-ON86257D74.0053EAB1-86257D74.0054A804@us.ibm.com>
Hi Jason, The default to the native host language semantics is a key change wrt. ARIA 1.1. Both SVG2 and HTML5 have defined native host language semantics (in terms of ARIA semantics). Currently, SVG2 points to ARIA 1.1. HTML will but it is a matter of when. Browsers do implement the mechanism of applying the role that they first know how to support in the list of attributes. This was part of ARIA 1.0 going to candidate recommendation. What is critically important when we go to ARIA 1.1 is if an author chooses to not add an ARIA role to fulfill the design of compound widget (like a Grid) then if the semantics match the design pattern it should work. Here is an example: <table role="grid"> <row> <th role="columnheader">foo</th> </row> <row> <td role="gridcell">foo</td> </row> </table> In this case row does not need a role of "row" for ARIA 1.1 whereas in ARIA 1.0 it would. This will help reduce download size. We have not yet assessed the implementation status of using the native host language semantics as part of the role computation but we will certainly need to for ARIA 1.1. Rich Rich Schwerdtfeger From: "White, Jason J" <jjwhite@ets.org> To: Richard Schwerdtfeger/Austin/IBM@IBMUS, James Craig <jcraig@apple.com> Cc: Chris Fleizach <cfleizach@apple.com>, David Bolter <dbolter@mozilla.com>, Dominic Mazzoni <dmazzoni@google.com>, PF <public-pfwg@w3.org>, "Alexander Surkov" <surkov.alexander@gmail.com> Date: 10/17/2014 10:00 AM Subject: RE: Element.getComputedRole() From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] it is not a platform role it is the role that the browser knows about. So, in the following example: <section role="chapter group"> If the browser knew how to map a role of chapter it would return "chapter". If the browser did not know how to map a role of chapter then it would look to a role of group. If it knew how to map a group role it would return "group" If the browser did not know about a role of "group" it would return the default native ost language role value for the <section> element which should be "region" The only exception to this would be where the host language held restrictions on the use of role. For example, if you were not allowed to put a grid on <button> you would return a role of "button" In this example, the query method is only needed because you have specified multiple (space-separated) values of the attribute. This is allowed by the ROLE attribute specification, but I would be interested to know the status of its implementation – specifically, whether user agents will successively process each value in the ROLE attribute until one is recognized, and supply a default value if not. Where a single role is specified and it conflicts with strong host language semantics, obviously the computed role can differ from that specified as the value of the content attribute, hence there is still a use case for the query method. However, having multiple roles specified in the attribute (if and when supported) establishes a stronger case, provided of course that Web applications need to be able to determine which role has been applied to a given element node. This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance.
Attachments
- image/gif attachment: graycol.gif
Received on Friday, 17 October 2014 15:25:14 UTC