Re: Modification to the role attribute definition

Thank you for the detailed response. Please see below.


Rich Schwerdtfeger



From:	Jeremie Patonnier <jeremie.patonnier@gmail.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	SVG WG <public-svg-wg@w3.org>, SVG public list <www-svg@w3.org>
Date:	02/05/2014 06:48 AM
Subject:	Re: Modification to the role attribute definition



Hi :)


2014-02-02 Richard Schwerdtfeger <schwer@us.ibm.com>:
  I modified the definition of the role attribute to not be limited to
  rendered elements. We should not limit these to rendered elements.

  Unlike HTML, virtually all of SVG does not have strong native host
  language semantics where we would need to restrict the use of role value.
  Consequently, there is not a lot of value creating a strong native host
  language mapping table like we did in HTML. In HTML we chose to produce
  an entire table that state what roles could be applied to what elements
  and what would not. However, like HTML there are some SVG elements where
  we would have not intention of mapping them to a specific role on a
  platform accessibility API. HTML5 calls these elements has having "no
  role". In this case ARIA considers these as having role of "presentation"
  and would not be mapped to platform accessibility API. Examples of this
  in HTML5 would be <title> and <script>. Examples of these in SVG would be
  <title> and <desc> which would be used in the computation of the name and
  description of an element which would have a role value.


Is there some priority between the <title> and <desc> to compute an element
text alternative? The way <title> is defined in SVG (it's a tooltip stuff
equivalent to the HTML title attribute) and according to the ARIA spec (
http://www.w3.org/TR/wai-aria-1.1/roles#namecalculation), it seams that any
<title> element should be compute after the <desc> elements. However, the
naming of <title> and <desc> could confuse author that could think that
<title> as some priority over <desc> or that the DOM order is relevant. I
think it worth make a clear statement about the way those two elements
should be compute to render the text alternative. FWIW, I think it should
follow the DOM order if there is no explicite use of aria-label attributes.


<rss>I agree that title and description should be separated in their use
and they should be clearly differentiated so as not to confuse authors. In
platform accessibility APIs we have two concepts called the accessible
"name" and the accessible "description". The name is essentially a very
short label where as description is meant to be a longer description
(help). In ARIA name computation the title attribute should be used as a
very last resort in the name computation (aria-label would have precedence)
as the title attribute has a duel purpose (to show a tooltip). If there is
no name that could be computed an assistive technology would use the
description if it were available. The description would be determined by a
combination of aria-describedby and <description>


Description would contribute to the accessible description computation. See
section 5.5.1 aria-describedby accessibility API mapping:
http://www.w3.org/WAI/PF/aria-implementation/#mapping_state-property_table


</rss>






  So, rather than having a mapping table I chose to limit the SVG elements
  which support the role attribute.

  Please review the new definition:
  https://svgwg.org/svg2-draft/struct.html#roleattribute

  The SVG elements for which we allow the role attribute are currently
  defined in the SVG attribute index
  https://svgwg.org/svg2-draft/attindex.html
  Also each element that specifies aria attributes has the role attribute
  included in the list.

  I need to look at issues 39 and 40. Note: we could refer to the Role
  attribute module: http://www.w3.org/TR/role-attribute/


Regarding issue 40, I think "default" should be replace by "presentation"
or we should provide a default mapping. AFAIK, it is what is currently done
by UA: no mapping to accessibility APIs.
  Related to this discussion, we agreed to produce and SVG 2.0 User Agent
  Implementation Guide along with a Core (Mostly the ARIA User Agent
  Implementation Guide today) and an HTML 5.1 User Agent Implementagion
  Guide. These guides provide normative mappings to platform accessibility
  API services.

  <rss>Currently, blink and webkit map SVG objects to groups if you provide
  any form of text alternative. I agree that without any alternative text
  we should provide no mapping or "presentation" because SVG objects are
  persistent and if we did not do this we would creating an accessibility
  tree in memory that included objects of no value unnecessarily increasing
  the memory footprint. I am not sure yet how to represent this.  you would
  want to say "presentation" | or possibly "group" if alternative text is
  applied </rss>


Some rough suggestion:
      <svg> should be map to the role "img"   <rss>This is a tough one as I
      think it is too restrictive. Images are considered bitmapped graphics
      where you would not expect to see sub-objects that are navigable.
      Where we are going is to be able to describe the parts of a drawing,
      how they relate to each other, etc. Some parts may also become
      widgets. What we did with canvas is simply expose a canvas role. What
      I think need to do is default to some sort of graphics container. We
      can always override it with role of "img">/rss>
      <g> should be map to the role "region"
      <rss> Regions are large perceivable areas that often show up as
      generic landmarks in AT. I would map <g> to "group">

      <a> should be map to the role "link" . <rss> agree </rss>
      other should be map to the role "presentation"  <rss>yes with the
      caveat that the addition of text would provide a role. We can cover
      this in the User Agent Implementation Guide for SVG</rss>


  Rich


  Rich Schwerdtfeger


--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat