Re: Proposed rewording for 1.10.1

Hi, Jan,

Thanks for putting together a draft. However, I have a few concerns about this wording (as I did about earlier versions):

1.    What to show: It doesn't really make clear what information should be presented. For example, it is presumably any text contained in the header cells for the row and column a cell, but if the contents of the header cell is an image, is it the image, or some text alternative for the image, or is it up to the developer? If it simply showed an arrow pointing to the header itself, would that comply?

2.    When to show it: The previous wording made it clear that it was about showing information related to a single item, rather than a mode that shows such information all all items in the content, but that distinction is lost in the new wording. Do we want to specify one or the other, or leave it open? It might make sense to have a mode where every form control has an adjacent label, but does that work, for example, for every cell in a large table? Since many column and row headings will be considerably longer than the cell content, the content might be hard to see. On the other hand, requiring the user to invoke a command and display a dialog box every time they want to

3.   Parallel construction: The sentence structure should probably be consistent with that of 2.3.3, which is currently "The user can have any recognized direct commands in rendered content (e.g. accesskey, landmark) be presented with their associated elements (e.g. Alt+R to reply to a web email)", and similarly with 2.3.4. That is, they should probably be consistent on whether they 2.3.3's "the user can have", and "presented with their associated elements", or the new proposal's "presents" and "adjacent labels for". I tend to lean towards "the user can".

4.    The title: The title should be changed to match the final form of the SC: the former says "show related elements" but the SC does not require showing any elements, but rather (I presume) information from or about those elements (e.g. the text in the heading cell for the current column). It really seems to be about displaying labels that are provided by other, related elements.

5.    Additional cases: The list of specifics is probably needed, but should it also cover a few more cases such as figcaption and aria-labeledby? Those could be specified using technology-neutral terms like "recognized captions for images", "recognized labels for controls", and "recognized labels for table rows and columns" (or just "recognized labels for images, controls, and table rows and columns").

6.    "Headers" vs. "Headings" vs. "Labels": Should the names of columns and rows be referred to as "headers", "headings", or "labels"? The term "header" is somewhat ambiguous, as it normally refers to a specific type of element, but we mean it in a more technology-neutral sense, and it also confuses the element with the information that element contains. Perhaps it would be clearer to refer to recognized row and column headings for a given table cell. On the other hand, I also think it's bit confusing for a sentence to use the word "labels" in two different senses, in this case "present adjacent labels for...form control labels", so I'd recommend using the word only for things the user agent recognizes in content, rather than instances of additional information it displays on its own.

     Thanks,
     Greg

-------- Original Message --------
Subject: Proposed rewording for 1.10.1
From: Richards, Jan <jrichards@ocadu.ca>
To: UAWG <w3c-wai-ua@w3.org>, simon.harper@manchester.ac.uk <simon.harper@manchester.ac.uk>
Date: 6/19/2014 10:37 AM
> Hi all (and especially Simon if you're following),
>
> Currently we have:
> 1.10.1 Show Related Elements: The user can access related elements based on the user's position in content (e.g. show the label of a form control, show the headers of a table cell). (Level AA)
>
> Comment: SH04 says: For 1.10.1 are we assuming that close elements will be close in the DOM. I'd think this would be hard based on the visual rendering, and would require some idea of the semantics of the association. I'd also think that a label to a form element could be close in DOM for distant in the visual rendering based on the CSS, how is this handled? (http://jspellman.github.io/UAAG-LC-Comment/)
>
> Group recognizes current wording will be hard to test....
>
> I suggested (and then we ran out of time)...handle is not great...:
>
> 1.10.1 Show Related Elements: The *user agent* presents adjacent labels for at least the following element relationships: (Level AA)
> - form control labels
> - table cell headers
>
> ed: I wrote this to try and hit the two examples listed at http://jspellman.github.io/UAAG/Implementing-UAAG20/#sc_1101
>
> 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
>