Re: Proposed rewording for 1.10.1

Per ACTION-995 (Recraft 1.10.1 based on today's discussion [on Greg Lowney - due 2014-07-10]), how about the following wording:

1.10.1 Access Related Information: The user can access information from explicitly-defined relationships in the content, including at least the following (Level AA):
* label for a control or image (e.g. HTML label element, figcaption and aria-labelledby attributes)
* caption for a table
* row and column labels for a table cell

This version, based on email and the last conference call:
a) reverts to the older language of "explicitly-defined relationships" (rather than the "related elements" used in later drafts), thus not requiring heuristics to infer relationships based on spatial proximity;
b) reverts to the older language of "access information" rather than "access elements" (to avoid confusing it with navigation);
c) does not require the number or letter of a table row or column (per Jeanne's request);
d) clarifies that it's about presenting information for a specified element, rather than for all elements simultaneously;
e) adds caption for table (per Simon's email);
f) limits the requirement to a specified list of relationships, rather than leaving it open ended (as the latter could not be easily tested);
g) leaves the presentation method open, so it can be done using a dialog box rather than an adjacent label (contrary to Jan's suggestion, and it may be controversial);
h) uses the "user can" phrasing (instead of "user agent presents", for consistency with related SC);
i) changes the title (hopefully better matching the SC).

     Greg

-------- Original Message --------
Subject: Re: Proposed rewording for 1.10.1
From: Simon Harper <simon.harper@manchester.ac.uk>
To: Greg Lowney <gcl-0039@access-research.org>, Richards, Jan <jrichards@ocadu.ca>, UAWG <w3c-wai-ua@w3.org>
Date: 7/2/2014 11:30 PM
> Thanks Jan and Greg, - Jan's changes passe dme bye, sorry!
>
> SO what about something like...
>
>
>
> 1.10.1 Show Adjacent and Related Labels: The *user agent* presents labels for at least the following element relationships: (Level AA)
> - adjacent form control labels
> - adjacent table cell headings
> - elements explicitly related in the html
>
> Now Greg (inline) ...
>
>
> On 03/07/2014 08:10, Greg Lowney wrote:
>> 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?
>
> I'd imagine that this would be caught by the other SC related to alternative descriptions and the like.
>
>>
>> 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.
>
> I don't see that...
>
> 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.
>
> Agree
>>
>> 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 athttp://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
>>> Ejrichards@ocadu.ca
>>>
>>
>