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 02:25:03 UTC