- From: David Bolter <david.bolter@gmail.com>
- Date: Wed, 02 Feb 2011 14:47:12 -0500
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- CC: Steve Faulkner <faulkner.steve@gmail.com>, wai-xtech@w3.org
- Message-ID: <4D49B4C0.3090503@gmail.com>
Hi Rich, Thanks. I want to hash this out for clarity and ideas. So I think one thing (call it "A") you are proposing is that the a web developer can do this: 1. <input type="checkbox" aria-posinset="5"> aria-posinset is not listed in the "Global States and Properties", but the fact that this HTML element is in all other respects semantically equivalent to: 2. <div role="checkbox" aria-posinset="5"> means we should allow the aria-posinset to work. I'm fine with A (and it should already work in gecko because we don't require the role attribute). The part of the proposal (call it "B") where we expose a role object attribute for 1 when there was no author supplied role attribute is the part I'm unsure about. It is this part I want a few AT vendor's feedback on. I'm fine with it pending positive feedback :) One advantage might be that if AT end up looking to the role object attribute first (before the enumerated desktop role), then we can have a greater path to extensibility*. * Note: sort of like how gecko already naughtily exposes a BSTR MSAA role for cases where there is no good enumerated role mapping. This is usually the element tag name. Cheers, David On 02/02/11 1:31 PM, Richard Schwerdtfeger wrote: > > Yes, we is the browser manufacturer. We are defining the HTML to API > mappings. > > What I am saying is you have: > > <input type="checkbox"> this has an aria semantic of checkbox. So, > simply pass the role="checkbox" name value pair in the object > properties to the AT > > same for: > > <tr> this has an aria semantic of "row". So, simply pass the > role="row" name value pair in the object properties to the AT > > However, > > For those elements that have NO ARIA equivalent like <details> pass > the role="details" name value pair. In other words you pass the tag > name as the role. > > I want to avoid requiring the author having to place roles on elements > with equivalent pre-defined samantics and I want the AT not to have to > inspect the role and the tag name. > > Does that help? > > > > Rich Schwerdtfeger > CTO Accessibility Software Group > > Inactive hide details for David Bolter ---01/28/2011 01:04:06 PM---Hi > Rich, Gecko's exposure of the tag as an object attribute David Bolter > ---01/28/2011 01:04:06 PM---Hi Rich, Gecko's exposure of the tag as an > object attribute predates ARIA so I'm > > From: David Bolter <david.bolter@gmail.com> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS > Cc: Steve Faulkner <faulkner.steve@gmail.com>, wai-xtech@w3.org > Date: 01/28/2011 01:04 PM > Subject: Re: HTML 5 Accessibility Mappings > > ------------------------------------------------------------------------ > > > > Hi Rich, > > Gecko's exposure of the tag as an object attribute predates ARIA so > I'm not sure can remove it. I don't understand "for all HTML elements > that don't have a pre-defined ARIA semantic we simply pass the role > value as the tag name". > Who is "we"? (The browser?) > What does passing the role value mean? > Did you mean 'tag name' or 'role attribute value'? > > Regarding the AT and author error, it is up to them whether they want > to correct or not; gecko provides the info. > > If you are proposing AT look at the IA2 role object attribute and > ignore the MSAA role, and if AT agree to this, I would support making > changes to gecko to use the role object attribute as more than just > the raw author supplied role attribute value, in a way I think you are > describing. > > Cheers, > D > > On 28/01/11 1:42 PM, Richard Schwerdtfeger wrote: > > David, > > The point being that today you need an ARIA role to be able to > apply aria attributes. Yet, HTML 5 defines default ARIA > semantics for many of the elements removing the need for the > author to define an aria role to apply the aria attributes that > are applicable to that role. If the author overrides the role > using role="foo" then that replaces the role. So there is no > reason for the author to expose roles separately if for all HTML > elements that don't have a pre-defined ARIA semantic we simply > pass the role value as the tag name. > > I don't see the value for providing the DOM element tag name and > the role attribute. Perhaps I am missing something. Are you > asking the AT to correct an author error? > > What I am proposing would actually reduce the number of object > attributes as you don't need to pass the tag name and the role - > just the role. > > Rich > > Rich Schwerdtfeger > CTO Accessibility Software Group > > > > From: David Bolter _<david.bolter@gmail.com>_ > <mailto:david.bolter@gmail.com> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS > Cc: Steve Faulkner _<faulkner.steve@gmail.com>_ > <mailto:faulkner.steve@gmail.com>, _wai-xtech@w3.org_ > <mailto:wai-xtech@w3.org> > Date: 01/25/2011 03:12 PM > Subject: Re: HTML 5 Accessibility Mappings > ------------------------------------------------------------------------ > > > > Hi Rich, > > Thanks for posting this. > > Note gecko exposes a 'tag', 'element-name' pair already so the > (corrected) #3 would imply duplicated object attributes. I think > I would like to expose the role and the element name separately > so that AT can decide on its own workarounds. I'm open for > debate on that. > > I'm not how "What this does for the author is it allows the > author to supply ARIA states and properties to elements that do > not have a role supplied but depend on the native ARIA semantics > as defined by the HTML 5 specification." is strictly dependent > on what we expose via the object attribute. It seems like a > separate issue. > > Note for number 4, gecko almost always overrides the > element->desktop role mapping and trusts the author. We don't > really validate the role attribute against the element name. > Having both the role and tag object attributes allows the AT to > decide what is best. I realize there are pros and cons to this > design. > > The proposal seems to be heading towards using object attributes > as the new defacto API (why bother with our existing enumerated > MSAA/IA2 roles) for browsers. I like the idea of having a more > flexible extensible API. Overall I have had push back from devs > like Jamie (NVDA) about overusing the object attributes, so I'm > interested to hear his feedback on this thread. > > Cheers, > David > > On 25/01/11 3:45 PM, Richard Schwerdtfeger wrote: > Yes Steve. Thank you for the correction. > > > Rich Schwerdtfeger > CTO Accessibility Software Group > > Inactive hide details for Steve Faulkner ---01/25/2011 10:50:13 > AM---Hi Rich, you wrote:Steve Faulkner ---01/25/2011 10:50:13 > AM---Hi Rich, you wrote: > > From: Steve Faulkner _<faulkner.steve@gmail.com>_ > <mailto:faulkner.steve@gmail.com> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS > Cc: _wai-xtech@w3.org_ <mailto:wai-xtech@w3.org>, > _david.bolter@gmail.com_ <mailto:david.bolter@gmail.com> > Date: 01/25/2011 10:50 AM > Subject: Re: HTML 5 Accessibility Mappings > ------------------------------------------------------------------------ > > > > Hi Rich, > > you wrote: > > 3. For HTML elements that have default ARIA role semantic we > pass the HTML element name as the role in the name value pair > passed in the object attributes sent to the AT > > shouldn't this be? > > "For HTML elements that have NO default ARIA role semantic..." > > regards > stevef > > On 25 January 2011 16:40, Richard Schwerdtfeger > <_schwer@us.ibm.com_ <mailto:schwer@us.ibm.com>> wrote: > In HTML 5 we introduce the concept of native host language > semantics in terms of ARIA roles for all HTML elements. I would > like to propose the following > > 1. All HTML elements should provide a role attribute in the > corresponding accessible object through the object attributes > (such as in IAccessible2) > 2. For HTML elements that have an ARIA equivalent role that role > should be passed as the role name/value pair in the object > attributes unless the author overrides the default elements role > in the object attribute > 3. For HTML elements that have default ARIA role semantic we > pass the HTML element name as the role in the name value pair > passed in the object attributes sent to the AT > 4. For HTML elements with an allowable ARIA role attribute that > is provided by the author we pass that role as the role > attribute in the object attributes > > What this does for the author is it allows the author to supply > ARIA states and properties to elements that do not have a role > supplied but depend on the native ARIA semantics as defined by > the HTML 5 specification. > > A case in point: > > <table tabindex="0" role="grid" aria-activedescendant="idx"> > <tr> > <th>vegetables</th><th>fruits</th> ... > </tr> > <td id="idx" role="gridcell">broccoli</td><td > role="gridcell>apple</td> ... > </tr> > </table> > > > TR has a native host language ARIA semantic of "row" but no role > is needed. > <TH> defeaults to columnheader and so on. > > Feedback? > > Rich Schwerdtfeger > CTO Accessibility Software Group > > > > > -- > with regards > > Steve Faulkner > Technical Director - TPG_ > > __www.paciellogroup.com_ <http://www.paciellogroup.com/>| > _www.HTML5accessibility.com_ > <http://www.html5accessibility.com/>| > _www.twitter.com/stevefaulkner_ > <http://www.twitter.com/stevefaulkner> > HTML5: Techniques for providing useful text alternatives - > _dev.w3.org/html5/alt-techniques/_ > <http://dev.w3.org/html5/alt-techniques/> > Web Accessibility Toolbar - > _www.paciellogroup.com/resources/wat-ie-about.html _ > <http://www.paciellogroup.com/resources/wat-ie-about.html> > >
Received on Wednesday, 2 February 2011 19:48:01 UTC