RE: role="text" and text frames

I think that's basically what the text pattern is. But, I'm not completely sure I understand. What would having that accessible do?

-----Original Message-----
From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: Thursday, February 11, 2016 12:46 AM
To: Cynthia Shelly <cyns@microsoft.com>; 'Joseph Scheuhammer' <clown@alum.mit.edu>; 'Alexander Surkov' <surkov.alexander@gmail.com>
Cc: 'James Teh' <jamie@nvaccess.org>; 'Richard Schwerdtfeger' <schwer@us.ibm.com>; wai-xtech@w3.org; public-aria@w3.org
Subject: RE: role="text" and text frames

Hmmm. So you would almost need a completely new kind of accessible that has the "text" as one of its properties. A textobject that could be a container for all the elements that are squashed by the text role.

-----Original Message-----
From: Cynthia Shelly [mailto:cyns@microsoft.com] 
Sent: Wednesday, February 10, 2016 2:46 PM
To: Matt King <a11ythinker@gmail.com>; 'Joseph Scheuhammer' <clown@alum.mit.edu>; 'Alexander Surkov' <surkov.alexander@gmail.com>
Cc: 'James Teh' <jamie@nvaccess.org>; 'Richard Schwerdtfeger' <schwer@us.ibm.com>; wai-xtech@w3.org; public-aria@w3.org
Subject: RE: role="text" and text frames

Here's the tricky thing, though...
In UIA "treat it as text" generally means that it doesn't have a separate element. It's just a range in the larger text pattern for the page. There are some (line or format, I'm not sure) breaks around it. That's what we do, for example, for <table role=presentation> and its children.

-----Original Message-----
From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: Tuesday, February 9, 2016 8:45 AM
To: 'Joseph Scheuhammer' <clown@alum.mit.edu>; Cynthia Shelly <cyns@microsoft.com>; 'Alexander Surkov' <surkov.alexander@gmail.com>
Cc: 'James Teh' <jamie@nvaccess.org>; 'Richard Schwerdtfeger' <schwer@us.ibm.com>; wai-xtech@w3.org; public-aria@w3.org
Subject: RE: role="text" and text frames

Joseph,

Stepping away from the technical details a moment ...

Conceptually, a presentational image is one that does not have any meaning; it is eye candy.

But, the images included in the examples in the text role do have meaning. The text role is not making a case for removing the image, but instead saying that authors should have a way to hint that screen readers may want to read the image as text. The text role is based on the premise, I think, that this is more friendly to screen reader users when reading. I personally do not regard it as more friendly to me, but that is a personal choice.

If the point of the text role is to completely remove access to and visibility of the image, then I think we are jumping into hot water. 
By removing access, we would be asking authors to make a judgment as to whether or not any blind user would ever desire to know that the meaning is communicated by an image. I don't know how an author could ever answer that question.

As a blind user, for example, I would never choose to have emoticons represented as text. I need to be culturally aware of their use and even learn to use them appropriately in some circles. Similarly, if I am reading a text for school, and if part of the discussion is the author's use of imagery, then I would not be part of the discussion if the publisher of the document used the text role for all the images embedded in the text.

As a matter of providing equal access to information, the implementation of the text role absolutely can not put the image out of reach. Again, this is radically different from presentational images, which,by the way, screen readers can choose to see if they want. I can tell my screen reader to show all images, even those with no alt text.

Personally, I would make sure that my default screen reader setting ignores the text role. Then, I would turn it on if the images became annoying.

So, I think the API working group needs to revisit the implementation of the text role to make sure that accessible objects exist for the images. And, perhaps we need an "assistive technologies SHOULD" statement in the text role to make sure that there is a way to ignore the text role.

Matt

-----Original Message-----
From: Joseph Scheuhammer [mailto:clown@alum.mit.edu] 
Sent: Tuesday, February 9, 2016 7:25 AM
To: Matt King <a11ythinker@gmail.com>; 'Cynthia Shelly' <cyns@microsoft.com>; 'Alexander Surkov' <surkov.alexander@gmail.com>
Cc: 'James Teh' <jamie@nvaccess.org>; 'Richard Schwerdtfeger' <schwer@us.ibm.com>; wai-xtech@w3.org; public-aria@w3.org
Subject: Re: role="text" and text frames

Hi Matt,

> Cynthia, if that is how it would work, does that mean that it would be literally impossible for the screen reader user to be aware of the image? Like, for example, there would not be any way for the screen reader to provide an option to ignore the text role?

I believe that is the point of the text role.  In this case it means, "there is no image here, just text".

>
> Would the image context menu be out of reach?

I suppose so.  Does an <img role="presentation"> have an image context menu?  That's another case where the <img> is not exposed in the a11y tree.  See the final text in Rich's email for the ACTION-1380 effort [1].  If a presentational image allows interaction with a context menu, then, Houston, we have a problem, since there in no accessible in the AAPI to hang that menu off of.

Your question might be relevant to ISSUE-1011. [2]  The presentation/none role section calls out a number of restrictions on its use.  Issue-1011 suggests similar restrictions for the text role.

>
> Matt

[1] https://lists.w3.org/Archives/Public/public-aria/2016Jan/0178.html

[2] https://www.w3.org/WAI/ARIA/track/issues/1011


-- 
;;;;joseph.

'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
                  - C. Carter -

Received on Thursday, 11 February 2016 20:16:27 UTC