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