W3C home > Mailing lists > Public > public-aria@w3.org > January 2016

Re: ACTION-1380 Proposed text

From: James Craig <jcraig@apple.com>
Date: Wed, 20 Jan 2016 20:35:47 -0800
Cc: public-aria@w3.org
Message-Id: <A4B1F538-5651-4D7A-9B1F-0CB73E386F33@apple.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
You still don't need to distinguish raster versus vector. It's incorrect to do so because it precludes raster image formats that contain object data like the PNG example below.

How about the following text in a Note.

"""
When aria-hidden="true" is applied to an element, the element and all descendant elements are removed from the accessibility tree. If aria-hidden="true" is applied to an image, the entire image is removed from the accessibility tree. 

When role="none" (or role="presentation") is applied to an element, the element's role semantics are removed, but the element's descendants remain exposed to the accessibility APIs. Most images do not have descendants elements, so the end result of applying role="none" is that entire element is removed, as if aria-hidden="true" had been applied. When an image has accessible descendants (e.g. <img src="example.svg"> or <svg>), applying role="none" will remove the image role semantics, but the element's descendants remain exposed to the accessibility APIs. 
"""


> On Jan 20, 2016, at 7:37 AM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
> 
> I agree 1 is unnecessary.  
> 
> revised proposed text:
> 
> 
> There is a distinct difference between what occurs when either role=none or role=presentation versus aria-hidden="true" is applied to a raster image versus a vector graphics drawing (SVG element). In the case of a raster image (e.g. <img src="foo.jpg") all descendants are considered presentational or having no role resulting in the both the image and any of its descendants not being exposed to the assistive technology regardless of which of these settings are applied. However, in the case of a vector graphics image (e.g. <img src="foo.svg"> or <svg>) all of the descendants are not required owned elements, by default, and may not have semantics that would indicate their being presentational or having no role. Therefore, if role="presentation" or role="none" is applied to a vector graphics drawing only the container is not exposed to the assistive technology and each of the descendant elements are exposed based on the SVG host language. If the author wants all descendant elements to be presentational the auhor may need to mark them with role "presentation" or "none". However, if aria-hidden="true" is applied to an vector graphics image the container and all its descendants are hidden from the assistive technology. 
>  
> be inserted before the text found in role="presentation":
>  
> "For any element with an explicit or inherited role of presentation, user agents MUST ignore any non-global, role-specific WAI-ARIA states and properties. However, the user agent MUST always expose global WAI-ARIA states and properties to accessibility APIs, even if an element has an explicit or inherited role of presentation."
>   
> 
> Rich Schwerdtfeger
> 
> -----James Craig <jcraig@apple.com <mailto:jcraig@apple.com>> wrote: -----
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> From: James Craig <jcraig@apple.com <mailto:jcraig@apple.com>>
> Date: 01/20/2016 02:26AM
> Cc: public-aria@w3.org <mailto:public-aria@w3.org>
> Subject: Re: Action-1380 Proposed text
> 
> It seems arbitrary to make a distinction between raster and vector here. Nothing prevents raster images from including object data. For example, Adobe Fireworks famously used the comment space of the raster PNG format to store vector and other source file data. What about ASCII art, which is neither vector nor raster? What about vector images that contain one or more raster images?
> 
> I think the distinction you are trying to make is… does the image have meaningful descendants or not? If so, I think there are two choices:
> 
> 1. Add a new role or attribute to differentiate the two types. (I don't think this is necessary.)
> 
> 2. Require authors to hide any presentational descendants of images. <img src="raster"> will default to having no descendants, while <img src="vector"> and <svg> will default to having descendants presumed to be meaningful. Edge cases like ASCII art may need some extra massaging by the author to hide the descendant nodes from the accessibility APIs.
> 
> James
> 
> 
>> On Jan 19, 2016, at 10:59 AM, Richard Schwerdtfeger <schwer@us.ibm.com <mailto:schwer@us.ibm.com>> wrote:
>> 
>> I propose that the following text:
>>  
>> There is a distinct difference between what occurs when either role=none or role=presentation versus aria-hidden="true" is applied to a raster image versus a vector graphics drawing (SVG element). In the case of a raster image all descendants are considered presentational or having no role resulting in the both the image and any of its descendants not being exposed to the assistive technology regardless of which of these settings are applied. However, in the case of a vector graphics image all of the descendants are not required owned elements, by default, and may not have semantics that would indicate their being presentational or having no role. Therefore, if role="presentation" or role="none" is applied to a vector graphics drawing only the container is not exposed to the assistive technology and each of the descendant elements are exposed base on SVG host language. However, if aria-hidden="true" is applied to an vector graphics image the container and all its descendants are hidden from the assistive technology. 
>>  
>> be inserted before the text found in role="presentation":
>>  
>> "For any element with an explicit or inherited role of presentation, user agents MUST ignore any non-global, role-specific WAI-ARIA states and properties. However, the user agent MUST always expose global WAI-ARIA states and properties to accessibility APIs, even if an element has an explicit or inherited role of presentation."
>>  
>> 
>> Rich Schwerdtfeger
>> 
> 
> 


Received on Thursday, 21 January 2016 04:36:20 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:18 UTC