- From: Al Gilman <Alfred.S.Gilman@ieee.org>
- Date: Fri, 12 Dec 2008 14:57:18 -0500
- To: W3C WAI-XTECH <wai-xtech@w3.org>
On 12 Dec 2008, at 9:57 AM, Aaron M Leventhal wrote: > > 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. You're not talking about a small change; you're talking about no change, if that's all you want. The present language already allows that. All it says now is that where the API accepts only one role, you have to use the one computed as given. <quote cite="http://lists.w3.org/Archives/Public/www-archive/2008Dec/ att-0018/01-part#ua_role_explicit"> 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> [Editorial: and yes, for American English, we need to s/which/that in that sentence] If the API accepts more than one, the API mapping is, by not being stated here, Implementation Defined. We haven't said how to extract two widget roles from the attribute. We didn't say that because it's not cross-API. If in the implementation guidelines you want to get API-specific and talk about how to load both role and sub-role properties, and make that cross- browser on that platform, that's new work I don't want to hold up the progress of this spec. Look again, I think that what you are doing in the browser is entirely in conformance with this, and carrying the whole list in another property does not violate this paragraph, nor would an API mapping that assigns a prime role per this algorithm and any number of additional or alternate roles by however works best for them. Mostly we need to talk about this and stop batting it around by email, and we need to hear from the other browsers and hopefully someone inside the the Mac API. 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/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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Received on Friday, 12 December 2008 19:58:02 UTC