Re: WAI-ARIA language providing for strong and weak implicit semantics from host language.

I just don't see any purpose in an upper limit on how many roles to expose 
to a platform a11y API, especially if that API allows more than one. We 
don't even know what other platform a11y APIs might be invented before 
ARIA 2 comes out. Since ARIA allows 0-n roles, the platform API should be 
able to choose how to deal with that.

>From my point of view, the purpose if the text were discussing here is to 
ensure that everyone knows there can be no role, and what that means. It 
means either 1) expose a neutral or null role of some kind, or 2) if there 
is really nothing interesting about that DOM node, it's not necessary to 
expose the object at all

- 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 05:16 PM
Subject:
Re: WAI-ARIA language providing for strong and weak implicit semantics 
from    host language.




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
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>