- From: Fred Esch <fesch@us.ibm.com>
- Date: Tue, 11 Nov 2014 16:45:27 -0500
- To: Matthew King <mattking@us.ibm.com>
- Cc: Steve Faulkner <faulkner.steve@gmail.com>, James Craig <jcraig@apple.com>, Joanmarie Diggs <jdiggs@igalia.com>, W3C WAI Protocols & Formats <public-pfwg@w3.org>
- Message-ID: <OF3CBCC08B.CA684AC1-ON85257D8D.00763986-85257D8D.0077845E@us.ibm.com>
+1 to what Matt said. This has more down side than up side. Authors will be confused by declaring text as text with a text alternative and/or aria-label. Accessibility does not benefit from being this complex. Regards, Fred Fred Esch Accessibility, Watson Innovations AARB Complex Visualization Working Group Chair IBM Watson Group From: Matthew King/Fishkill/IBM@IBMUS To: Joanmarie Diggs <jdiggs@igalia.com> Cc: Steve Faulkner <faulkner.steve@gmail.com>, James Craig <jcraig@apple.com>, W3C WAI Protocols & Formats <public-pfwg@w3.org> Date: 11/11/2014 03:29 PM Subject: Re: First draft of ARIA 1.1. "text" role Joan Marie wrote: > But to me, the solution to the problem means "don't present > 'image'". It does not mean "present 'text'". I agree with this view of the 2nd set of examples. I am still baffled by the ARIA 1.0 rationale that makes <img role="presentation" alt="My Image" src="MyImage.jpg">, which has a text equivalent of "My Image", synonomous with both <img role="presentation" alt="" src="MyImage.jpg"> and <img role="presentation" src="MyImage.jpg">. True the image tag does not technically have "content" but alt is a text alternative, which is referred to as "alternitave text content" and treated as text content when images are turned off in the browser. Had I been around early enough in ARIA 1.0, and had the chops, I may have argued to have the first sentence of the definition of role presentation: "An element whose implicit native role semantics will not be mapped to the accessibility API." consistently applied to image with alt considered to be the text content of the image. I think this would be far less confusing. In fact, the current spec text doesn't clearly say that this is not the case. Especially since the image example in the spec has alt="" in it, a reader could reasonably deduce that the image alt text is preserved as text when role presentation is applied. If alt text on images was recognized by ARIA implementations as the text content of an image, then there would be no need for a text role to support images that are used as text. In this case, <img role="presentation" alt="My Image" src="MyImage.jpg"> would be the same as the proposed <img role="text" aria-label="My Image" src="MyImage.jpg"> which would be the same as <img role="text" alt="My Image" src="MyImage.jpg">. The potential for these 3 image elements to be rendered differently for screen reader users of ARIA 1.1 implementations does not give me the feeling that we are moving in the direction of reducing complexity and increasing clarity for authors. Extended characters are another story. The problem is that they really are text. So then Joanie's other point is really impoartant: > When you tell an assistive technology "this object is text," I think > it's reasonable for that assistive technology to assume that there > is text present, that the platform's accessible text interface isimplemented, etc. And that's not the case here. In the case of the text role applied to a span containing text (whether or not it contains extended characters), it seems we are giving authors the ability to create what are essentially alternative "speech" or in effect "non text" equivalents of the text -- a more screen reader friendly description of text. In general, empowering or encouraging authors to recast text as something other than text specifically for screen readers feels slippery and kind of dangerous. I wonder how often it will be put in place, intentionally or ignorantly, and then forgotten. Who would think to "look behind" text to find alternative text when testing? We label images, form elements, widgets, etc., but text? I wonder if we would ever see something like: <span role="text" aria-label="I know what blind people want to hear...something different">This is what sighted people should read and it is what the author is really saying</span>. The downside risk is magnified when you consider that role text could replace all descendants. If creating screen reader-specific, context dependent rendering of extended unicode text is the primary problem we need to solve, then ARIA 1.0 has a solution: <span aria-hidden="true">crazy sightee characters</span><span aria-hideden="false" style="display:none">screen reader friendly text</span> Unfortunately, some browsers still do not support the 2nd span so the old hack of off-screen positioning is still required. I would guess the main advantage of the new text role over this approach is that you can use a single element instead of 2. Are there others? The question I am pondering is whether it is really worth adding such a risky and complex role to gain this advantage? And, is the use of the text role going to be as transparent to authors as the aria-hidden attribute? Matt King IBM Senior Technical Staff Member I/T Chief Accessibility Strategist IBM BT/CIO - Global Workforce and Web Process Enablement Phone: (503) 578-2329, Tie line: 731-7398 mattking@us.ibm.com Joanmarie Diggs <jdiggs@igalia.com> wrote on 11/11/2014 04:44:37 AM: > From: Joanmarie Diggs <jdiggs@igalia.com> > To: Steve Faulkner <faulkner.steve@gmail.com>, > Cc: James Craig <jcraig@apple.com>, W3C WAI Protocols & Formats > <public-pfwg@w3.org> > Date: 11/11/2014 04:45 AM > Subject: Re: First draft of ARIA 1.1. "text" role > > Hey Steve. > > On 11/11/2014 06:29 AM, Steve Faulkner wrote: > > > > On 11 November 2014 02:38, Joanmarie Diggs <jdiggs@igalia.com > > <mailto:jdiggs@igalia.com>> wrote: > > > > confuses me. Unlike the first set of examples, there is no actual > > (rendered) text there because the element is an image. So why should > > this non-textual object be exposed to accessibility APIs as plain text? > > > > > > Hi JoanMarie, > > > > <img alt="some text"> > > > > I think, is one of the main use cases for role=text, what it does is > > ensure that when a developer (as if often the case unfortunately) uses > > images of text/symbols/icons to convey meaning, through the use of > > role=text the textual information is conveyed without the role=img > > noise. The fact that an image is being used to provide it is an artifact > > of design/technology constraints rather than being important information > > (role=img) that is conveyed. In these cases, the medium is not the message. > > Understood. But to me, the solution to the problem means "don't present > 'image'". It does not mean "present 'text'". > > When you tell an assistive technology "this object is text," I think > it's reasonable for that assistive technology to assume that there is > text present, that the platform's accessible text interface is > implemented, etc. And that's not the case here. > > --joanie >
Attachments
- image/gif attachment: 1C247817.gif
- image/jpeg attachment: 1C395087.jpg
- image/gif attachment: graycol.gif
Received on Tuesday, 11 November 2014 21:45:59 UTC