Re: Proposed rewording for 1.10.1

+1


On Wed, Jul 9, 2014 at 10:35 PM, Greg Lowney <gcl-0039@access-research.org>
wrote:

>  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>
> <simon.harper@manchester.ac.uk>
> To: Greg Lowney <gcl-0039@access-research.org>
> <gcl-0039@access-research.org>, Richards, Jan <jrichards@ocadu.ca>
> <jrichards@ocadu.ca>, UAWG <w3c-wai-ua@w3.org> <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> <jrichards@ocadu.ca>
> To: UAWG <w3c-wai-ua@w3.org> <w3c-wai-ua@w3.org>,
> simon.harper@manchester.ac.uk <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
>
>
>
>
>


-- 
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964