RE: role="text" and text frames

>I don’ agree that the text role can be ignored. I think that would be very bad - especially in the case of SVG.


Rich, are you saying that screen reader users should not have the option to see the actual content? Obviously, such an option wouldn’t always be valuable, but certainly for the kind of examples provided in the spec, I would rather have the actual content than the cover up made by the text role.


An engineered solution that completely blocks access to the actual content will reduce accessibility, not improve it.


I am also wondering how this type of transformation will be received by screen reader users who have some sight. They see graphics, but their screen reader can not find the graphic.




From: Rich Schwerdtfeger [] 
Sent: Tuesday, February 9, 2016 8:52 AM
To: Matt King <>
Cc: Joseph Scheuhammer <>; Cynthia Shelly <>; Alexander Surkov <>; James Teh <>; Rich Schwerdtfeger <>;;
Subject: Re: role="text" and text frames


I ran this by Freedom Scientific and if a role is chosen they agree it ought to be for STATIC text. 


So, this is bigger than just an image. In SVG the author can draw text using drawing strokes. By applying a role of text you can determine the text being drawn and we could make it searchable. 


If we make this the text role the AT should have enough knowledge that it is either a raster image or a vector drawing and that the text equivalent for the text drawn is what is to be rendered. Static text is important in that it would allow the text to be read to the user when placed in a line of text. Text frame would not work that way. It would be treated as a separate entity much the same way we handle TDs when role=“presentation”  is applied to a  table. 


I don’ agree that the text role can be ignored. I think that would be very bad - especially in the case of SVG.




Rich Schwerdtfeger




On Feb 9, 2016, at 10:44 AM, Matt King < <> > wrote:



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.


-----Original Message-----
From: Joseph Scheuhammer [] 
Sent: Tuesday, February 9, 2016 7:25 AM
To: Matt King < <> >; 'Cynthia Shelly' < <> >; 'Alexander Surkov' < <> >
Cc: 'James Teh' < <> >; 'Richard Schwerdtfeger' < <> >; <> ; <> 
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.




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


Received on Wednesday, 10 February 2016 05:40:22 UTC