Re: HTML 5 Accessibility Mappings

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



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>
      To:        Richard Schwerdtfeger/Austin/IBM@IBMUS
      Cc:        Steve Faulkner <faulkner.steve@gmail.com>,
      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>
      To: Richard Schwerdtfeger/Austin/IBM@IBMUS
      Cc: wai-xtech@w3.org, 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>
      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 | www.HTML5accessibility.com |
      www.twitter.com/stevefaulkner
      HTML5: Techniques for providing useful text alternatives -
      dev.w3.org/html5/alt-techniques/
      Web Accessibility Toolbar -
      www.paciellogroup.com/resources/wat-ie-about.html