W3C home > Mailing lists > Public > public-pfwg@w3.org > October 2014

RE: Element.getComputedRole()

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">
<th role="columnheader">foo</th>
<td role="gridcell">foo</td>

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 Schwerdtfeger

From:	"White, Jason J" <jjwhite@ets.org>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS, James Craig
Cc:	Chris Fleizach <cfleizach@apple.com>, David Bolter
            <dbolter@mozilla.com>, Dominic Mazzoni <dmazzoni@google.com>,
            PF <public-pfwg@w3.org>, "Alexander Surkov"
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
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.

(image/gif attachment: graycol.gif)

Received on Friday, 17 October 2014 15:25:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:10 UTC