Re: Proposed rewording for 1.10.1

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
>>
>

-- 
*READ-ME*

  1. I'll be on holiday from the 12th to 26th July without email contact.
  2. If you'd like a timely response then get email to me before Sunday 06th July; I can't
     guarantee to respond after that date.


Too brief? Slow response? See the Email Charter <http://emailcharter.org>

------------------------------------------------------------------------------------------

Simon Harper <http://www.manchester.ac.uk/research/simon.harper/>

  1. Contact Me <http://simon.harper.name/contact/>
  2. Web Ergonomics Lab <http://wel.cs.manchester.ac.uk>