- From: Al Gilman <Alfred.S.Gilman@ieee.org>
- Date: Wed, 10 Dec 2008 11:11:32 -0500
- To: Aaron M Leventhal <aleventh@us.ibm.com>
- Cc: W3C WAI-XTECH <wai-xtech@w3.org>, wai-xtech-request@w3.org
On 10 Dec 2008, at 4:02 AM, Aaron M Leventhal wrote: > > The OS X accessibility protocol allows a subrole, which is a more > detailed role. This allows apps to expose a role that older > versions of VoiceOver would understand, and a newer more specific > subrole for later versions. > > Therefore, we probably shouldn't say that there can't be more than > one. Instead, I would explain when there could be no role, and in > those cases the UA should expose either a totally neutral role that > means no role, or not expose the object at all. I think we have them covered. Note that we agreed to defer role extension to the 2.0 version of ARIA. So the idea that there would be a browser that recognizes a precise role and an AT that only recognizes its more general down-level super-role is a future thing. OS X has subroles now, but we don't have a need to feed them sub/super- role pairs yet. An AT as of 1.0 is either going to recognize the sub-role or not recognize the super-role. [I am going to call them the precise role and the general role from here on in in the discussion, as they can be ancestor and descendant by generic/ specific and not merely immediate next steps in the derivation graph.] In the case of an up-level browser than knows about role extension and 2.0 roles with a layered AT that only knows about the 1.0 roles, it is probably a better idea for the browser to *compute the super-roles of the "applicable ARIA role" from the definition of that role* rather than depend on what the author has done to put super-roles in the list after the precise role. Authors *should still* put down-level-recognizable super-roles in the list in the @role attribute value to support down-level _browsers_, but the up- level browsers should go from the dsub/super-relationships declared in the published definition of the precise role to determine the chain of "precise role and down-level ancestors" to expose to AT. Note that in </quote cite=""> 7.3.2.5. Applicable ARIA role rules, in accessibility API binding The applicable ARIA role, if there is one, MUST be the role value which is mapped to the value of a role property in any accessibility API which accepts only one role value. </quote> s/which/that -- for U.S. English APIs that allow subroles are exempted from using the "applicable ARIA role" and that value *only*. We could add a note, something informative, on the order of: Future versions of WAI-ARIA might define extension mechanisms by which sub-roles of specification-published roles can be defined by publications other than versions of this specification. In that case, APIs that allow sub-roles in addition to roles would be well advised to do the following on encountering an extension or later-published role that is a specialization of a down-level role: expose the down-level super-role as 'role' and the extended role as 'sub-role.' On second thought, I think that we can broaden that if we move it to the Implementation Guidelines. Where we have the API capability to expose role and sub-role, the 'role' should expose a super-role of the narrowest-applicable role in any case where the OS knows that there are ATs that only understand the super-role and won't understand the sub-role. That's not limited to ARIA situations. They can expose a multi-selectable tablist as sub-role='accordion' if the API defines an 'accordion' role. That is for the API binding implementation to handle and define. [Editorial note: I am consciously avoiding the plain-English use of 'should' and 'may' in this informative prose, as I think this is good editorial practice in a document that uses RFC-2119 terms in normative provisions.] Al > > > - Aaron > > > From: Al Gilman <Alfred.S.Gilman@ieee.org> > To: Aaron M Leventhal/Cambridge/IBM@IBMUS > Cc: W3C WAI-XTECH <wai-xtech@w3.org>, wai-xtech-request@w3.org > Date: 12/10/2008 03:25 AM > Subject: Re: WAI-ARIA language providing for strong and weak > implicit semantics from host language. > > > > > > > On 8 Dec 2008, at 6:56 AM, Aaron M Leventhal wrote: > > > > > > I fear that no matter how we describe the two factors, given that > > the > > > explicit ARIA role can be present or absent and the implicit ARIA > > role > > > can be strong, weak, or absent, we still wind > > > up with the same five cases in the bullet list in "7.3.2.2. > > Overview." > > > > I think the bulleted list is a good start but should be simplified > > by saying something like: > > 1. If the native markup gives precedence to its own implicit > > semantics, or there is no ARIA role, use the native markup to > > determine the role (if the native markup does not provide a role, > > do not expose one). > > 2. Otherwise, use the ARIA role > > OK, > > In the latest cut it reads like > > <quote > cite="http://lists.w3.org/Archives/Public/www-archive/2008Dec/ > att-0018/01-part#ua_role"> > Depending on the precedence assigned by the host language, the > applicable ARIA role may come from the host language semantics, from > the expicit ARIA role, or there man be none. If there is no explicit > ARIA role or the native markup takes precedence, use the native > markup to determine the role. Otherwise, use the explicit ARIA role. > There may be one, or there may be none, but not more than one. > </quote> > > Al > > > - Aaron > > > > > > > > From: Al Gilman <Alfred.S.Gilman@ieee.org> > > To: W3C WAI-XTECH <wai-xtech@w3.org> > > Date: 12/05/2008 09:44 PM > > Subject: Re: WAI-ARIA language providing for strong and weak > > implicit semantics from host language. > > > > > > > > > > > > > > On 4 Dec 2008, at 5:32 AM, Aaron M Leventhal wrote: > > > > > > > > Hi Al, > > > > > > I believe there is no need for the middle "weak" concept. > > > We only need strong or no semantics. The semantically strong > > > constructs are immune from ARIA. > > > > > > Also, for each construct specified, whether they have a default > > > ARIA role or provide additional ARIA properties is an additional, > > > separate decision. > > > > I agree with the logic. > > > > A. some language constructs have implicit properties > > (including states and roles in properties, here) regardless whether > > 'weak' or 'strong' > > > > B. some of these implicit properties are strong, i.e. take > precedence > > over explicit ARIA markup. > > > > I'm not sure how re-organizing things this way simplifies the WAI- > > ARIA spec. It's pretty much > > how I addressed things. But I have fiddled the prose to make it > read > > more like this. The new > > v.3 is at: > > > > http://lists.w3.org/Archives/Public/www-archive/2008Dec/att-0014/01- > > part > > > > I fear that no matter how we describe the two factors, given that > the > > explicit ARIA role can > > be present or absent and the implicit ARIA role can be strong, weak, > > or absent, we still wind > > up with the same five cases in the bullet list in "7.3.2.2. > > Overview." > > > > http://lists.w3.org/Archives/Public/www-archive/2008Dec/att-0014/01- > > part#ua_role_overview > > > > > So, this document would ultimately be simplified into two groups: > > > http://hsivonen.iki.fi/aria-html5-bis/ > > > > > > FWIW, Henri Sivonen, the original author of the strong/weak/no > > > concept, agreed that it's a good simplification. > > > > > > > > > - Aaron > > > > > > > > > From: Al Gilman <Alfred.S.Gilman@ieee.org> > > > To: W3C WAI-XTECH <wai-xtech@w3.org> > > > Date: 12/04/2008 03:24 AM > > > Subject: WAI-ARIA language providing for strong and weak implicit > > > semantics from host language. > > > > > > > > > > > > > > > > > > > > > Re: > > > http://www.w3.org/WAI/PF/Group/track/issues/67 > > > http://lists.w3.org/Archives/Public/www-archive/2008Dec/ > att-0011/01- > > > part > > > > > > This is a 'scratch draft' that is to say forked from the main > > line of > > > Editor's draft versions. It is a strawman rewrite of 6.2 and > 7.3 to > > > make room for host languages to provide built-in semantics > > > that takes over from ARIA markup where appropriate. > > > > > > Please read over the draft and see if there is > > > > > > a) a simpler way to say it that is still correct. > > > b) anything we missed. > > > > > > Al > > > > > > > > > > > > > > > > > > > > > > > >
Received on Wednesday, 10 December 2008 16:12:17 UTC