Re: Updated ISSUE-206 CP

How about just suggesting some sort of notification of the image, without overconstraining what it is? In general, we let assistive technologies (or really UA/AT combos) have a lot of freedom in how they handle repair of broken content. For Safari+VoiceOver, saying "Image" might be a good way to handle these in general. But we might want to get more fancy - for instance, we could special-case the situation where the image has a sensible filename (for example "architecture-diagram.png" or "cat.jpg" instead of "IMG17567.JPG"). And I would not presume to dictate what is right for other ATs.

BTW, I appreciate that John did research on this question!

Regards,
Maciej

On Aug 21, 2012, at 5:18 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

> How about suggesting the use of an aural notification to the screen
> readers when an image is reached/passed in the DOM. Something like a
> bleep. This goes beyond what we can do here, though it means that
> solutions may not always be necessary to be stuck into HTML.
> 
> Just my 2c worth. :-)
> 
> Cheers,
> Silvia.
> 
> On Wed, Aug 22, 2012 at 9:26 AM, John Foliot <john@foliot.ca> wrote:
>> (adding the Accessibility TF mailing list to the mix)
>> 
>> Edward O'Connor wrote:
>>> 
>>> Hi all,
>>> 
>>> I've updated my Change Proposal for ISSUE-206 (meta-generator) based on
>>> all the great discussion that's happened on the list since I originally
>>> posted it. As before, the Change Proposal is on the WG's wiki here:
>>> 
>>>         http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-206
>> 
>> 
>> Hi Ted,
>> 
>> One key point that emerged during the list conversation
>> (http://lists.w3.org/Archives/Public/public-html/2012Aug/0067.html) is that
>> this new attribute should have, at a minimum, a default accessible name that
>> would be conveyed to the Accessibility APIs.
>> 
>> One current effect of applying alt="" is that it silences screen readers
>> from attempting to provide a heuristicly derived accessible name
>> ("H6rGT8.jpg") and it also loosely maps to role="presentation". If we are to
>> create a new attribute that has an impact on this existing legacy behavior,
>> we should be providing a default accessible name to offset any attempt to
>> heuristically generate one.
>> 
>> Earlier this month I had a series of telephone and skype conversations with
>> a number of blind users whom I know personally. All of them have a slightly
>> higher-than-average understanding of web technologies, but all are, most
>> importantly, daily screen reader users. I was curious to know their thoughts
>> on the meta-issue (not the meta tag issue, but the larger discussion), and
>> what they would want/expect as a behavior when we tag an image with an
>> indicator that a textual equivalent is not available (user-experience). I
>> also spoke to a few web accessibility professionals who do not normally
>> spend time at the W3C, but who none-the-less spend their time, energy and
>> passion on ensuring accessible web content is created (and specifically,
>> they were Jared Smith of WebAIM, and Glenda Sims of Deque). The list of
>> people I spoke to is limited, and not necessarily representative of all
>> screen reader users, but it is/was a start.
>> 
>> UX: the unanimous feedback I heard was that yes, if an important image is on
>> a page, and even if there is no textual equivalent provided, that they
>> (non-sighted users) want to know of the existence of the image.
>> 
>> *How* we communicate that was less unanimous, but that underlying desire
>> does exist. The differences here were centered mostly around cognitive value
>> of the feedback (what would the screen reader say?), and the balancing of
>> verbosity (overly chatty/too much information actually gets in the way).
>> Whether it is because of how I expressed or explained the situation to my
>> colleagues I cannot say, but all shared my concern of how/what the UX for
>> the non-sighted user would be. One person (Victor Tsaran - Yahoo!) suggested
>> that all he would want to hear is "Image" (or "Graphic") with nothing else:
>> the end user would then assume or presume that there is something there, and
>> seek assistance. Another (Everett Zufelt) suggested that screen readers
>> could speak "Image: without description", while others were ambivalent about
>> specific wording. All however wanted to ensure that whatever is communicated
>> is clear to the end user.
>> 
>> (As an aside, none of the current new attribute proposals address this
>> concern, and so all are incomplete at this time IMHO. Any of the 3 new
>> attributes will also need to have a mechanism that informs users that "this
>> is an important image that lacks any textual alternative", so the
>> interaction with AT tools needs to be addressed.)
>> 
>> Ted, I'd be a lot more enthusiastic of your revised Change Proposal if it
>> addressed this need.
>> 
>> Cheers!
>> 
>> JF
>> 
>>> -----Original Message-----
>>> From: Edward O'Connor [mailto:eoconnor@apple.com]
>>> Sent: Tuesday, August 21, 2012 2:55 PM
>>> To: public-html@w3.org
>>> Subject: Updated ISSUE-206 CP
>>> 
>>> Hi all,
>>> 
>>> I've updated my Change Proposal for ISSUE-206 (meta-generator) based on
>>> all the great discussion that's happened on the list since I originally
>>> posted it. As before, the Change Proposal is on the WG's wiki here:
>>> 
>>>         http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-206
>>> 
>>> Many people commented that calling the attribute relaxed="" is
>>> problematic, and several other names have been propsed. Based on the
>>> design princples in [1], the analysis in [2], and other emails on the
>>> subject, I've changed the proposed attribute's name to
>>> generator-unknown-alt="".
>>> 
>>> On the plus side, this name is more concise than the very-long
>>> generator-unable-to-provide-required-alt="", and it conveys several
>>> important facts:
>>> 
>>> 1. the fact that the generator has omitted alt="",
>>> 2. that the reason the generator omitted alt="" is that proper alt=""
>>>   text is unknown to the generator,
>>> 3. and, unlike relaxed="", the name doesn't imply that this feature
>>>   could be used for other cases of relaxed validation.
>>> 
>>> On the minus side, it's longer than relaxed="".
>>> 
>>> I haven't altered the Change Proposal with regard to conformance
>>> checker
>>> behavior. As before, conformance checkers MAY report <img> elements
>>> without alt="" even when they have generator-unknown-alt="", but the
>>> Change Proposal does not advocate any particular UI for this. I trust
>>> Mike and Henri will come up with something better than what I would
>>> come
>>> up with.
>>> 
>>> 
>>> Ted
>>> 
>>> 1. http://lists.w3.org/Archives/Public/public-whatwg-
>>> archive/2012Aug/0004.html
>>> 2. http://lists.w3.org/Archives/Public/public-whatwg-
>>> archive/2012Aug/0038.html
>> 
>> 
>> 
>

Received on Wednesday, 22 August 2012 01:30:33 UTC