RE: Proposed rewording for 1.10.1

I like this, except I'm not sure about HTML specific info in the SC itself.

-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<mailto:jrichards@ocadu.ca?Subject=Re%3A%20AUWG%20Teleconference%20for%2017%20March%202014%20%28Boston%20time%20has%20changed%20-%20%20please%20re-check%20time%29&In-Reply-To=%3C0B1EB1C972BCB740B522ACBCD5F48DEB012E4B50AC%40ocadmail-maildb.ocad.ca%3E&References=%3C0B1EB1C972BCB740B522ACBCD5F48DEB012E4B50AC%40ocadmail-maildb.ocad.ca%3E>

________________________________
From: Greg Lowney [gcl-0039@access-research.org]
Sent: July-09-14 11:35 PM
To: Simon Harper; Richards, Jan; UAWG
Subject: 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><mailto:simon.harper@manchester.ac.uk>
To: Greg Lowney <gcl-0039@access-research.org><mailto:gcl-0039@access-research.org>, Richards, Jan <jrichards@ocadu.ca><mailto:jrichards@ocadu.ca>, UAWG <w3c-wai-ua@w3.org><mailto: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><mailto:jrichards@ocadu.ca>
To: UAWG <w3c-wai-ua@w3.org><mailto:w3c-wai-ua@w3.org>, simon.harper@manchester.ac.uk<mailto:simon.harper@manchester.ac.uk> <simon.harper@manchester.ac.uk><mailto: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<mailto:Ejrichards@ocadu.ca>