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.

> 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.
>
Some rough suggestion:

   - <svg> should be map to the role "img"
   - <g> should be map to the role "region"
   - <a> should be map to the role "link"
   - other should be map to the role "presentation"


>
> Rich
>
>
> Rich Schwerdtfeger
>
-- 
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>