Re: ACTION 1.11.2

Hi Simon, a couple of thoughts on this.

(Actually, my major thought is it's depressing how quickly simple questions turn out to be so much more complicated than they sound!)

First of all, we need to decide and clarify whether 1.11.1 and 1.11.2 are meant to be about exposing information directly to the user (e.g. by the option of having the link's title displayed in brackets immediately following it) or to assistive technology (e.g. expose it via a platform accessibility API or through the DOM). The language of both success criteria were and remain ambiguous. The earlier Examples given for 1.11.1 included one that's about displaying to the user and one that's itself ambiguous; the only example in the rewrite is also somewhat ambiguous. Even reading the Intent paragraph for 1.11.2 left me unsure.

Any requirements about displaying information belongs under Principle 1 (Perceivable) but any about programmatic access belong in Principle 4 (Facilitate Programmatic Access). If we want both, which in some cases we probably do, then we need to make sure those properties are in both places.

As for programmatic side, I believe some of the states and properties in 1.11.1 are already covered in 4.1: 4.1.2 already covers exposing link element content (Name property) and link title (Description property), and and 4.1.6 *may* cover exposing whether it is selected--but the wording of 4.1.6 (Properties) is vague as to whether it requires exposing whether the element is selected (e.g. MSAA get_accState STATE_SYSTEM_SELECTED) or which of its child elements is selected (e.g. MSAA get_accSelection).

Whether or not a link has been recently visited is not called out in Guideline 4. It is presumably available through the DOM, which the user agent has to expose to assistive technology. I don't see a WAI-ARIA state flag for it.

I'm not sure what you mean by a "hover" status; whether the user agent is aware that a pointer is currently has paused over the element? I don't see a WAI-ARIA state flag for this, either. Can you clarify the intent?

SC 4.1.2 is actually ambiguous about the Description. Would that be the title attribute of nearly any element? Or would that be Longdesc when it is provided? Standards such as MSAA support text attributes of Name, Description, and Value, which for links would presumably be the link contents, title attribute, and href attribute respectively.

So if the intent is programmatic access, we could modify 4.1.6 (Properties) to include link status:
     j. whether a link has been recently visited

We could also fix the ambiguity regarding selection by modifying item (g) and adding an item (k):
     g. whether the element is currently selected
     k. which child element is selected, if any

I fear your 1.11.2 is not appropriate for exposing the information programmatically, because these properties aren't handled by any platform accessibility architecture that I know of, and Guideline 4.1 is all almost all about exposing through a platform accessibility architecture. That being said, 4.1.2 and 4.1.6 both ignore any properties that aren't handled by the platform accessibility architecture, so listing esoteric properties there will never cause any UA to fail, they'll just have no effect.

2. Both SC should certainly be explicitly limited to *recognized* attributes. Also, the user agent *can* programmatically determine some of these by generating extra web traffic (e.g. downloading the link target to measure it's size!) but we certainly don't want to encourage that, so we might also put in wording limiting this to properties that are recognizable without accessing additional remote resources, or something to that effect.

3. Why exclude x(html) files from 1.11.2? If it's because they're guaranteed to be opaque to the user (like an image might be), but they can be as large as other technologies.

4. In your Example for 1.11.2, I think you mean "a link pointing to an image" rather than "a link which is surrounding an image". I took the latter wording as meaning an img element inside an anchor element (e.g. <a href="a.htm"><img src="b.png" /></a>), but reading further on makes me think you meant a link pointing to an image (e.g. <a href="b.png">...</a>).

5. It would be helpful to provide a more detailed example of the UI you have in mind. For example, do you imaging the user actively querying some properties of a link, or the user agent to have a mode where those properties are displayed in immediate proximity to the links? Of if you're thinking purely of programmatic access then the example can be rewritten to clarify this before being moved to Guideline 4.

     Thanks,
     Greg

-------- Original Message  --------
Subject: ACTION 1.11.2
From: Simon Harper <simon.harper@manchester.ac.uk>
To: UAWG list <w3c-wai-ua@w3.org>
Date: 1/31/2011 8:55 AM
> Hi there,
>
> So this action was to rewrite 1.11.2. We removed 1.11.1 because the viewport aspects are handled in 1.8 - however looking at 1.11.2 it seems to me 'link title' is not extended information - in fact it seems to me more basic than viewport handling. In this case I propose we reinstate 1.11.1 as
>
> 1.11.1 (former 3.13.1) Basic Link Information:
>
> The following information is provided for each link (Level A) :
>
>     * link element content,
>     * link title
>     * link status (visited/selected/hover)
>
> The Intent for 1.11.1 actually relates to 1.11.2 but can be modified easily as follows:
>
>     * Intent of Success Criterion 1.11.1 (former 3.13.1):
>             o     Users who use screen readers need to be able to easily discover information about a link, including the title of the link in the event that the link content has the same text as other links on the page. Otherwise the effect of selecting that link is not distinguishable.
>     * Examples of Success Criterion 1.11.1 (former 3.13.1):
>           o Robert, who uses a screen reader, hears a list of links read out saying 'more', 'more', 'more'. The browser also displays the link title so that Robert can distinguish which link he must select.
>     * Related Resources for Success Criterion 1.11.1 (former 3.13.1):
>           o Web Content Accessibility Guidelines version 2.0
>
>
> Now I propose that we rewrite 1.11.2 to be:
>
>
> 1.11.2 (former 3.13.2) Extended Link Information:
>
> The following information is provided for each link which does not point to an (x)html file (Level AAA) :
>
>     * what will be the consequences of selecting the link (will a file download to desktop occur? Will a text file be opened by the browser?)
>     * technology type (of the linked Web resource)
>     * technology file size (of the linked Web resource)
>     * predicted time to load (of the linked Web resource)
>     * intra-page/onsite/offsite (whether the link is internal to the resource e.g., the link is to a target in the same Web page)
>
>
>
>     * Intent of Success Criterion 1.11.2 (former 3.13.2):
>             o Here we wish to mitigate the possibility of unexpected consequences occurring on link selection; this is especially the case for users who cannot see the visual cues present on the web page. For instance, visual styling can be used to imbue groups of simple links with semantic differences such as downloads or offsite links. This may then become a problem because links which seem the same to a user of assistive technology may have unexpected consequences when selected.
>
>     * Examples of Success Criterion 1.11.2 (former 3.13.2):
>           o Robert, who uses a screen reader, selects a link which is surrounding an image, the user agent downloads the image and displays the raw image file, Robert's assistive technology cannot describe the image or even say what has downloaded because raw images do not have alt elements and image downloaded and displayed is not an html file. If the user agent tells Robert that an image file download will occur on link selection he would not have made that choice as he cannot see the image.
>
>     * Related Resources for Success Criterion 1.11.2 (former 3.13.2):
>           o Web Content Accessibility Guidelines version 2.0
>
>