Indicate acceptance...Re: ACTION-875 re 1.2.1 Support Repair by Assistive Technologies

I am good with all of this. if we can agree on the list, we can discuss
other things on the call.
Greg +1 (he wrote it)
Jan +1
Jim +1

others?


On Tue, Sep 10, 2013 at 9:07 AM, Richards, Jan <jrichards@ocadu.ca> wrote:

>  Hi Greg,****
>
> ** **
>
> Sorry for not being available to help out with this, but you did a great
> job…****
>
> ** **
>
> **1.       **I agree with the proposed wording for 1.2.1 and it’s IERs****
>
> **2.       **I agree with adding the Conformance Applicability Note****
>
> **3.       **I agree with adding “1.2.3 Warn of Repair Text” at Level
> AAA. ****
>
> ** **
>
> Cheers,****
>
> Jan****
>
> ** **
>
> *(MR) JAN RICHARDS*
>
> PROJECT MANAGER****
>
> INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)****
>
> OCAD UNIVERSITY****
>
> ** **
>
> *T *416 977 6000 x3957****
>
> *F *416 977 9844****
>
> *E* jrichards@ocadu.ca****
>
> ** **
>
> *From:* Greg Lowney [mailto:gcl-0039@access-research.org]
> *Sent:* September-10-13 4:31 AM
> *To:* WAI-UA list
> *Subject:* ACTION-875 re 1.2.1 Support Repair by Assistive Technologies***
> *
>
> ** **
>
> Jan and I had ACTION-875 to propose rewording for this SC. As Jan's been
> away I've taken a stab at it.
>
> This SC had four problems. First, the wording could be a bit confusing.
> Second, portions of the Intent section and both of the examples were
> actually supposed to be for a different SC. Third, (as Kelly pointed out)
> it seemed to be prohibiting behaviors all the time, when really it should
> just be making sure that those behaviors can be avoided when they'd
> interfere with assistive technology. Below is a rewrite that tries to
> address the first two; for the third issue we can either add a lot of
> words, or we can add a note somewhere that would clarify *all* the SC.
> Fourth, it no longer addresses how repair text might be presented to users,
> even though that it described in one of the examples, so I propose a new SC
> that could handle that--or be postponed for future editions.
>
> As always, feedback is welcome.****
> Part 1. Background****
>
>
> Here is the existing wording:****
>
> 1.2.1 Support Repair by Assistive Technologies: If text alternatives for
> non-text content are missing or empty then both of the following are true:
> (Level AA)
> a.    The user agent does not attempt to repair the text alternatives with
> text values that are also available to assistive technologies.
> b.    The user agent makes metadata related to the non-text content
> available programmatically (and not via fields reserved for text
> alternatives).****
>
>
> The existing wording was proposed by Jan in email of 2012-04-19 based on
> ATAG2 wording; before that the SC was both much simpler but also much
> broader: ****
>
> 1.2.1 Repair Missing Alternatives: The user can specify whether or not the
> user agent should generate and render repair text (e.g. file name) when it
> recognizes that the author has not provided alternative content. (Level A)
> ****
>
>
> That earlier version was about repair text for assistive technology and
> presented directly to the user, but the revised version was just about
> supporting assistive technology.****
> Part 2, Proposed New Wording for 1.2.1****
>
>
> Assuming we're sticking with a focus entirely on assistive technology,
> here is a proposed minor rewrite that I think is slightly clearer. I've
> marked the changed phrases in asterisks. The Intent paragraph is mostly
> new. The reworked example should address the concerns of comment EO31 to
> the effect that it needed more directly relevant and/or explanatory
> examples.****
>
> 1.2.1 Support Repair by Assistive Technologies: If text alternatives for
> non-text content are missing or empty then both of the following are true:
> (Level AA)
> a. the user agent does not attempt to repair the text alternatives *by
> substituting* text values that are also available to assistive
> technologies.
> b. the user agent makes *other available* metadata related to the non-text
> content available programmatically, *but not via fields reserved for text
> alternatives*.
>
> Intent of Success Criterion 1.2.1:
>
> When alternative content is missing, it can be helpful for users to have
> access to other information, metadata such as the filename, which can be
> substituted as repair text. However, these are usually not as helpful as
> alternative content that was properly authored for the original document.
> In these cases assistive technology can provide users with a wider range of
> information, which may be more helpful than any one piece of repair text
> the user agent could provide. Therefore it is important that assistive
> technology have access to as much information about the non-text content as
> possible, but also to be able to tell that no author-provided text
> alternative is available. User agents should provide assistive technology
> with the available metadata for the non-text content, but not substitute
> repair text in ways assistive technology will mistake it for
> author-provided text alternatives.
>
> Examples of Success Criterion 1.2.1:
>
> Ray is blind and counts on alternative text for images. When his screen
> reader is reading a web page and encounters an image, it asks the user
> agent for alternative text. If the user agent reports that no alternative
> text is available, the screen reader accesses the DOM to retrieve the title
> attribute associated with the image, its original file name, and path to
> the downloaded image file. It extracts embedded metadata from the image
> file, such as its original title and caption fields. It can then tell Ray
> that there is an image with no alternative text, but provide him with the
> value it considers most likely or which Ray has selected through his
> preferences, and also provide a command that lets him hear the other
> values, and so make his own judgement about the nature and purpose of the
> image. ****
>
> ** **
> Part 3, Dealing with Always-On****
>
>
> We don't really want to require the user agent to always avoid providing
> repair text, but the current/proposed wordings ("the user agent does not
> attempt..." and "the user agent makes available...") do. We could either
> rephrase the SC with somewhat cumbersome wording such as "the user agent
> provides at least one operating mode where" or "assistive technology can
> have", or we could add a global applicability note to address this.****
>
> I suggest adding the following Note, or something like it, to section
> titled "UAAG 2.0 Conformance Applicability Notes":****
>
> Note: Throughout this document, all required behaviors may be provided as
> optional preference settings unless a success criterion explicitly says
> otherwise. For example, if a success criteria requires high contrast
> between foreground text and its background, the user agent may also provide
> choices with low contrast. A required behavior does not need to be the
> default option unless the success criteria explicitly says otherwise.****
>
> ** **
> Part 4, Warning User of Repair Text****
>
>
> I think the existing Bintu example shows why the user may want a warning
> when the user agent presents repair text instead of author-provided text
> alternatives, but if we want to include it I agree with Jan's implied
> suggestion that it should be a separate SC from that about assistive
> technology. We could postpone that, or add as something like the following.
> The existing Bintu example is moved here, with new text marked with
> asterisks.****
>
> 1.2.3 Warn of Repair Text: The user agent informs the user when it
> presents repair text in place of missing text alternatives. (Level AAA)
>
> Intent of Success Criterion 1.2.3:
>
> When alternative content is missing, it can be helpful for users to have
> access to other information which can be substituted as repair text.
> However, these are usually not as helpful as alternative content that was
> properly authored for the original document. They may also be less
> accurate, particularly when the user agent relies on useful but fallible
> technologies such as speech recognition or optical character recognition.
> Therefore it is useful for users to be warned when the text alternatives
> they are presented with are in fact repair text rather than author-provided
> text alternatives.
>
> Examples of Success Criterion 1.2.3:
>
> Bintu is deaf and relies on captions to replace audio. Bintu selects a
> caption button for a video she wants to watch, and is informed that no
> captions exist but that the user agent will try to generate some captions
> through automated means. The player then analyzes the video soundtrack and
> provides speech-to-text translation served as captions. *Because she was
> warned, she will be prepared to encounter more errors in the captions than
> if they had been authored by humans, and more likely to recognize errors
> when they occur.*
>
> Note: this is an advanced example, not a requirement.****
>
>
>     Thanks,
>     Greg****
>



-- 
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964