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

I'm talking about a small change. There would still be only 1 significant 
ARIA widget role.

But, however a platform API wants to expose that widget role is another 
matter. I don't want to limit that.
The platform might decide to expose an ARIA widget role using 2 roles, 1 
that's already known to current generation ATs, and a more specific role 
that newer ATs understand.

- 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/12/2008 03:46 PM
Subject:
Re: WAI-ARIA language providing for strong and weak implicit semantics 
from     host language.




On 12 Dec 2008, at 6:34 AM, Aaron M Leventhal wrote:

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

We might as well get it right, but this is a substantial change.

The history as I recall it is that we decided to put a limit
of one widget role at a time in the markup because the APIs mostly 
only accepted one.
And we compromised to say that there could be a landmark role at the
same time.

Then someone came along and proposed the algorithm of taking the first
recognized token in the list of tokens in @role.  This gave us extension
possibilities.  The up-level browser could accept a narrow, extended 
role and
the down-level browser could still have the fallback of the broader
ancestor role that the author would list later in the attribute.  Note
that this also implies a conflict resolution rule if the author blunders
and puts two widget role names in the list that are not descendant/ 
ancestor.

We can change the processing in V.1 so that the processing of the list
yields a filtered list of just the ARIA roles, still in the original 
order.

Then add the "use the first value that the API property supports" 
rule as a later step
on the condition "for any API property that takes role values and
accepts only one value."

But if we do this, we would re-write the whole role ontology more 
like UIA,
because we could have a role for the data structure, a role for each 
interface
that the object supports, and in the Browser guidelines boil this set 
of roles down to a
single role-name that best fits for the unique-role APIs and just 
pass through the
information to UIA more or less one-for-one.

That's a significant change to the ontology and to the browser 
processing.

Accordion and treegrid roles might fall out of this model more 
easily.  But it's
not a small or local change.

> 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

And from my point of view that's "how to handle the API's" which is 
part of
the Implementation Guidelines."  I don't think that the author should be
thinking in terms of "does this lead to a node with a null role or no 
node
at all in the accessible-object tree."  I know that is what you need 
to be
thinking about now, but I'm not sure that this is part of the 
implementation
that should float up into the spec.

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