Re: SC 2.7.2

Simon, I like the new stuff you've written. In the example it would be good to change "because it presents" to "because it can present", so it's clear that this would be an optional mode and not implying that it's a behavior a browser should do all the time.

I agree with the editor's note that the SC itself is still unclear. "Can access" is pretty vague, and the inline examples don't explain what has to be done beyond, say, than making sure a form control's label is not hidden. Is the SC saying that the user should be able to have the label for an element presented near that element (e.g. form control's label, or a table cell's row and column headings)? Wouldn't that also include the nested headings (h1, h2, etc.) that describe the structural position of the element? Or is it saying that the user should be able to navigate between things that have an explicit relationship?

There's also the difference between having information displayed with all elements that meet some criteria vs. having a command to display information for the element that has the selection or focus, so we should probably clarify what we would consider the more normal approach.

Might common implementations be to (a) have a keyboard command that presents an element's label near the element, for use when the user doesn't already see them presented together, and (b) have a mode where the full label is presented near the element (e.g. as a pop-up) when the pointer hovers over the element?

-------- Original Message  --------
Subject: SC 2.7.2
From: Simon Harper <simon.harper@manchester.ac.uk>
To: UAWG list <w3c-wai-ua@w3.org>
Date: 3/11/2011 3:05 AM

Still chomping my way through 2.7 - here is sc 2.7.2 for your perusal, there is an Editors note for this: 'postponed for more information about the intent of this SC. Is it about providing flyover information? Or is it out of place and really belongs in Principle 2' I'm just writing my interpretation so that we have somewhere to start.

2.7.2 (former 4.7.3) Access Relationships: The user can access explicitly-defined relationships based on the user's position in content (e.g., show form control's label, show label's form control, show a cell's table headers). (Level A)

Intent of Success Criterion 2.7.2 (former 4.7.3) :
HTML controls and elements are sometimes grouped together to make up a composite control; certain elements explicitly relate to others. This is the case with Ajax widgets and with form elements. By making sure the user can access these explicit relationships means that, say, visually disabled users can better understand these relationships even if the elements are not adjacent on the screen or the DOM.

Examples of Success Criterion 2.7.2 (former 4.7.3) :
John, has low vision and uses a screen magnifier to access his Browser. When interacting with tables and spreadsheets John has to move the viewport of the magnifier to understand the row and column titles of the cell with which he is interacting. This takes additional time and effort and is therefore frustrating. John has just purchased a new Browser because it presents the row and column titles when he hovers over a cell - this makes him much more productive at his accounting job.

Related Resources for Success Criterion 2.7.2 (former 4.7.3) :
WAI-ARIA
UAAG 2.7.3 Location in Hierarchy


Cheers