w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: w3c-archive@w3.org, jeanne@w3.org
This questionnaire was open from 2011-04-05 to 2011-04-21.
4 answers have been received.
Jump to results for question:
From the 2.7.1 email from Simon with edits from Jan's Comments on 2.7:
2.7.1 Discover navigation and activation keystrokes: Direct navigation and activation keystrokes are discoverable both programmatically and via perceivable labels. (Level A)
This is sometimes known as mouse-less browsing. Some users have problems controlling the mouse and/or the keyboard. Therefore users often find control by speech recognition to be advantageous. In this case it is much more efficient for navigation and activation selection points to be both viewable by the user and controllable by their assistive technology.
Mary cannot use the mouse or keyboard due to a repetitive strain injury, instead she uses voice control technology with uses a mouse-less browsing plug-in to her browser. The plug-in overlays each hyperlink with a number that can then be used to directly select it (e.g. by speaking the command "select link 12"). This prevents Mary from having to say the work 'tab' numerous times to get to her desired hyperlink.
Mouseless Browsing Firefox Extension:
https://addons.mozilla.org/en-us/firefox/addon/mouseless-browsing/
Perceivable navigation and activation keys:
http://www.mouseless.de/index.php?/content/view/17/30/
Choice | All responders |
---|---|
Results | |
Accept the proposal | 1 |
Recommend changes (see comments field) | 2 |
The proposal needs more discussion (see comments field) | 1 |
Disagree with the proposal | |
Neutral - will accept the consensus of the group |
Responder | 2.7.1 Discover navigation and activation keystrokes | Comments 2.7.1 |
---|---|---|
Jeanne F Spellman | Accept the proposal | |
Greg Lowney | The proposal needs more discussion (see comments field) | I'm afraid that we have previously-overlooked redundancy between 2.7.1 "Discover navigation and activation keystrokes" and the pair 2.1.6 "Present Direct Commands in Rendered Content" and 2.1.7 "Present Direct Commands in User Interface". I think the former (2.7.1 "Discover navigation and activation keystrokes") is the weaker version, because: 1. If exposing direct keyboard commands programmatically is required under Guideline 4 ("Facilitate Programmable Access"), we can just reference it here under the Related Resources, rather than repeating it in the SC itself; otherwise we'd end up with lots of SC repeating things in Guideline 4. 2. The title should be either a noun phrase or an imperative directed at the developer, whereas this one sounds like it's addressing the user. 3. I think the phrase "direct keyboard commands" is better than "navigation and activation keystrokes", as the latter would be broad enough to encompass direction keys and the like. I like some of Simon's proposed content, and would like to see those folded into 2.1.6/2.1.7 so they address both access keys and "mouseless browsing" functionality. We did not propose combining 2.1.6 and 2.1.7 because they currently have two different priorities. If we change them to be the same they could be combined the way 2.7.1 was. Also note that as part of our general work on looking at focus and keyboard issues, Kim and I are going to propose splitting 2.1 "Ensure Full Keyboard Access" into several smaller, more specific guidelines, and as such we'll propose renumbering many of them, including 2.1.6 and 2.1.7. |
Jim Allan | Recommend changes (see comments field) | use Jan's intent |
Jan Richards | Recommend changes (see comments field) | - I note Greg L's point about redundancy between 2.7.1 "Discover navigation and activation keystrokes" and the pair 2.1.6 "Present Direct Commands in Rendered Content" and 2.1.7 "Present Direct Commands in User Interface" - typo: buy=>by - Example is a barrier example not an implementation, is this intended? It might be reworded as follows: + Mary cannot use the mouse or keyboard due to a repetitive strain injury, instead she uses voice control technology with uses a mouse-less browsing plug-in to her browser. The plug-in overlays each hyperlink with a number that can then be used to directly select it (e.g. by speaking the command "select link 12"). This prevents X from having to say the work 'tab' numerous times to get to her desired hyperlink. |
From the 2.7.2 email from Simon:
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)
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.
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.
WAI-ARIA
UAAG 2.7.3 Location in Hierarchy
Choice | All responders |
---|---|
Results | |
Accept the proposal | 1 |
Recommend changes (see comments field) | 2 |
The proposal needs more discussion (see comments field) | 1 |
Disagree with the proposal | |
Neutral - will accept the consensus of the group |
Responder | 2.7.2 Access Relationships | Comments 2.7.2 |
---|---|---|
Jeanne F Spellman | Recommend changes (see comments field) | Reword example: John has low vision and uses a screen magnifier to access the tables and spreadsheets online that he needs for his accounting job. Instead of continually having to move the viewport of the magnifier to read the row and column titles of the cell with which he is interacting, John's browser presents the row and column titles when he hovers over a cell - this makes him much more productive at his job. |
Greg Lowney | The proposal needs more discussion (see comments field) | 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. "Access" explicitly-defined relationships doesn't make clear whether this means the user agent is required to let users view those relationships, or navigate by them, or both. 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? |
Jim Allan | Accept the proposal | |
Jan Richards | Recommend changes (see comments field) | - This one is tricky because of what counts as an explicitly defined relationship. I wouldn't exactly say an HTML table column header is explicitly defined. - Is the requirement really to provide label-type relationships (would need to be defined)? - intent should not be HTML specific. I think it is sufficient to say "structured content" (e.g. tables, forms, etc.) - the example is ok |
From the 2.7.2 email from Simon:
2.7.3 (former 4.7.4) Location in Hierarchy: The user can view the path of nodes leading from the root of any content hierarchy in which the structure and semantics are implied by presentation, as opposed to an explicit logical structure with defined semantics (such as the HTML5 Canvas Element), or as a consequence of decentralized-extensibility (such as the HTML5 item / itemprop microdata elements), and only if the user agent keeps an internal model of the hierarchy that it does not expose via the DOM or some other accessibility mechanism. (Level A) .
Knowing where you are in a hierarchy makes it easier to understand and navigate information. Users who are perceiving the data linearly (such as audio speech synthesis) do not receive visual cues of the hierarchical information. Efficient navigation of hierarchical information reduces keystrokes for people for whom a key-press is time-consuming, tiring, or painful. For people with some cognitive disabilities, providing the clear hierarchy reduces cognitive effort and provides organization. For instance, a media player provides a hierarchical display of playlists, albums, artists and songs, etc. When the user selects an individual item, a breadcrumb of the categories is displayed, can be navigated and is available programmatically.
Jane works for a leading PR company and has been blind from birth. Her job requires her to do a significant amount of Web surfing in gossip and human interest magazine sites. However, in the charge towards HTML5 many of these sites are replacing standard html content with slick 'Canvas' designs. While the hierarchical information is present (otherwise her browser would not be able to render it) this is not available to Jane. This means that her assistive technology has no way of gaining access to the information. Jane needs a browser which, where present, makes the canvas hierarchy explicit and available to both herself and her assistive technology; just like it does for the page DOM.
HTML5
WAI-ARIA
UAAG 2.7.2 Access Relationships
Choice | All responders |
---|---|
Results | |
Accept the proposal | |
Recommend changes (see comments field) | 1 |
The proposal needs more discussion (see comments field) | 3 |
Disagree with the proposal | |
Neutral - will accept the consensus of the group |
Responder | 2.7.3 Location in Hierarchy | Comments 2.7.3 |
---|---|---|
Jeanne F Spellman | Recommend changes (see comments field) | The SC has more examples of what it is not, then what it is. I find that confusing. What about: "The user can view the path of nodes leading from the root of any content hierarchy including those in which the structure and semantics are implied by presentation. " Then take the other examples and move them into the examples section. I'm not sure what (if anything) to do about the exception. Also, in the example, I would remove "gossip" and "slick" as they are judgemental. |
Greg Lowney | The proposal needs more discussion (see comments field) | New comments: A. Really needs some more specific, concrete examples of what you do and do not expect user agents to implement in order to comply with this requirement. B. The new wording of the SC suffers from dangling clauses. Its structure is essentially "So and so when A, not B, or C, and only if D", which could mean "when (A and not B) or (C and D)", or "when A and D and not (B or C)", etc. B. Some language in the example is still unclear to me. For example, when it says "While the hierarchical information is present (otherwise the browser would not be able to render it)", it seems a basic problem is that with HTML5 Canvas the browser can render content in which hierarchical information is implied by presentation (e.g. font sizes and location) but not present in any machine-understandable form. The last sentence in the example also fails to actually describe an example of expected behavior, and in fact makes it sound like the browser is supposed to expose information to the assistive technology, which would be appropriate under Principle 4 rather than here. Some comments from email of 3/31/10: 1. The current wording is not limited to displaying the path from the root to some particular node (e.g. the currently selected node in the presentation); it says "leading from" but should probably add something equivalent to a "to" clause. 2. I believe I understand what you're trying to say with the two categories, but I could be wrong, and in either case I don't think the distinction would be clear to someone who hadn't been in on our discussion. Are you saying that the user agent should expose hierarchies that are conveyed by the normal visual or audio presentation, but it is not required to expose hierarchies that may be present in the markup if they're invisible to the typical user? If that's right, can the group provide some examples of both categories? Or are you saying the HTML structure not be something the UA would represent for the SC, because it's "an explicitly logical structure with defined semantics"? If the hierarchy is already represented in the DOM, then it's already exposed to assistive technology, and if it's not already in the DOM, then how does the browser know it to expose it? 3. In the example, might list a tree along with breadcrumbs as typical ways of satisfying this criterion. 4. The Intent section talks about efficient keyboard navigation, but the success criterion doesn't address or require this. As written, it would be enough, for example, to provide a command to display a separate window with static text describing the hierarchy; that certainly would not help with navigation. If we want to make sure this provides navigation, then we could make the explicit, but isn't that overlapping section 2.7 (Provide structured navigation)? |
Jim Allan | The proposal needs more discussion (see comments field) | not sure canvas has hierarchy or semantics. Judging by the work of the CanvasA11y group the author has to supply all of this. Need a different example. I don't have one. |
Jan Richards | The proposal needs more discussion (see comments field) | - this is quite a wordy SC - I actually don't think I fully understand what it requires. " in which the structure and semantics are implied by presentation" seems to imply that the user agent needs to create explicit structure when it is implied by presentation. - Is this really Level A. |
From the 2.7.4 Attempt #2 email from Simon:
Simon's note: I'm wondering if this should move to 2.7.1 and everything else move down one?
2.7.4 (former 4.7.2) Direct navigation: The user can navigate directly to important (structural and operable) elements in rendered content. (Level A).
It is often difficult for some people to use a pointing device (the standard method of direct navigation) to move the viewport and focus to important elements. In this case some other form of direct navigation - such as numbers or key combinations assigned to important elements - should be available which can then be accessed via the keyboard or speech control technology.
See example for 2.7.1: Discover navigation and activation keystrokes
2.7.7 configure set of important elements
Choice | All responders |
---|---|
Results | |
Accept the proposal | 2 |
Recommend changes (see comments field) | 2 |
The proposal needs more discussion (see comments field) | |
Disagree with the proposal | |
Neutral - will accept the consensus of the group |
Responder | 2.7.4 Direct navigation | Comments 2.7.4 |
---|---|---|
Jeanne F Spellman | Recommend changes (see comments field) | Agreed that this should be 2.7.1 and renumber others. The example in current 2.7.1 should move/be repeated here. |
Greg Lowney | Recommend changes (see comments field) | Since other SC already require navigation and activation be available through the keyboard, the difference here is that we're saying some things, especially those used frequently, should be *efficiently* available from the keyboard--the most efficient means is by providing direct navigation/activation using a simple key combination or short sequence. That's the key aspect of this SC, so we should probably address that in the Intent paragraph. In terms of where this should go in the document, Kim and I are working on a proposal for reorganizing the keyboard/focus related success criteria along the following lines: 2.1 Ensure full keyboard access 2.2 Provide sequential navigation 2.3 Provide direct navigation and activation 2.4 Provide text search 2.5 Provide structured navigation |
Jim Allan | Accept the proposal | like moving it to 2.7.1. |
Jan Richards | Accept the proposal | - ok, except the intent should be worded more positively. It's what we intend to enable, not a problem description. |
From the 2.7.2 email from Simon:
2.7.5 (former 4.7.1) Access to Relationships which Aid Navigation: The user can access explicitly-defined relationships based on the user's position in content, and the path of nodes leading from the root of any content hierarchy to that position. (Level AA).
Let the user use the keyboard to navigate forwards and backwards through elements that they are likely to be interested in interacting with. These elements must include, but are not limited to, enabled links and controls. This allows the user to jump between elements without having to navigate through intervening content such as blocks of text. Efficient keyboard navigation is especially important for people who cannot easily use a mouse. Efficient keyboard navigation aids structured navigation by enhancing a users comprehension of their position (e.g., show form control's label, show label's form control, show a cell's table headers, etc.).
Jane has mobility problems and cannot use the mouse to make direct link selections. She uses the keyboard for all her interaction with the system and instead of selecting links with the pointing device she uses the browsers built in sequential navigation system by pressing the Tab key to move the focus to the next link or control in the page, and press Shift+Tab to move in the reverse order.
See 2.1.4 for a discussion of letting the user configure the list of important elements to suit their task.
Choice | All responders |
---|---|
Results | |
Accept the proposal | 1 |
Recommend changes (see comments field) | |
The proposal needs more discussion (see comments field) | 2 |
Disagree with the proposal | |
Neutral - will accept the consensus of the group | 1 |
Responder | 2.7.5 Access to Relationships which Aid Navigation | Comments 2.7.5 |
---|---|---|
Jeanne F Spellman | Accept the proposal | minor edits of the intent to make it more consistent with the style of other intents. |
Greg Lowney | The proposal needs more discussion (see comments field) | 1. "access" explicitly-defined relationships doesn't make clear whether this means the user agent is required to let users view those relationships, or navigate by them, or both. 2. The difference between this and the 2.7.3 (Location in Hierarchy) above seems unclear, especially since both mention "path of nodes", etc. Similarly, the wording and title are close enough to those of 2.7.2 (Access to Relationships) above as to leave the key differences unclear. 3. The example seems to be an example of sequential (forward and backward) navigation between operable elements, for which Kim and I are drafting a new proposal (specifically an SC "Sequential navigation between elements" under a Guideline "Provide sequential navigation"). |
Jim Allan | Neutral - will accept the consensus of the group | |
Jan Richards | The proposal needs more discussion (see comments field) | - the SC wording is too general. But trust me that I KNOW hard this is to define. We went through it in ATAG2. |
From the 2.7.6 email from Simon:
Simon's note: Maybe this should move to 2.7.2 and everything else move down one.
2.7.6 (former 4.7.5) Direct activation: The user can move directly to and activate any operable elements in rendered content. (Level AA)
It is often difficult for some people to use a pointing device (the standard method of direct navigation) to select links. In this case some other form of direct selection - such as numbers or key combinations assigned to important elements - should be available which can then be accessed via the keyboard or speech control technology.
See example for 2.7.1: Discover navigation and activation keystrokes
2.7.7 configure set of important elements
Choice | All responders |
---|---|
Results | |
Accept the proposal | 2 |
Recommend changes (see comments field) | 1 |
The proposal needs more discussion (see comments field) | |
Disagree with the proposal | |
Neutral - will accept the consensus of the group | 1 |
Responder | 2.7.6 Direct activation | Comments 2.7.6 |
---|---|---|
Jeanne F Spellman | Recommend changes (see comments field) | Because it is AA, it can't move to the .2 position, but it could be first in the AA. Because it is ALL operable elements, I don't think it should be Level A |
Greg Lowney | Neutral - will accept the consensus of the group | See comments above about Direct Navigation. Rather than saying "via keyboard or speech control technology" how about the more general "via keyboard and keyboard emulators (such as speech control technology)"? |
Jim Allan | Accept the proposal | |
Jan Richards | Accept the proposal | - Good. Just needs a more positive intent. |
From the 2.7.7 email from Simon:
2.7.7 (former 4.7.6) Configure Set of Important Elements: The user has the option to configure the set of important elements for structured navigation, including by element type (e.g., headers, list items, images). (Level AAA)
All users are not the same, all devices are not the same. What may be important for the efficient interaction of some users are not important for others. In this case, user agents should start with a general set of elements that may be important such as headers, list items, images, and like but enable the addition or removal of elements from this list as the user wishes.
John is on a low income and cannot afford both a general computer and a television. In this case, John accesses the Web via his digital television and uses a remote control to do this. By allowing John to customise the elements which are important to him, the embedded browser developers have helped John have a more fulfilling browsing experiences and speeded up his interaction with the web content he finds useful.
N/A
Choice | All responders |
---|---|
Results | |
Accept the proposal | 1 |
Recommend changes (see comments field) | 2 |
The proposal needs more discussion (see comments field) | 1 |
Disagree with the proposal | |
Neutral - will accept the consensus of the group |
Responder | 2.7.7 Configure Set of Important Elements | Comments 2.7.7 |
---|---|---|
Jeanne F Spellman | Recommend changes (see comments field) | Example - John has limited hand motion.... (needs an accessibility example) By allowing John to customize the elements which are important to him, John use his remote to move through a web page by the list elements which speeds his interaction with the web content and reduces motor strain. |
Greg Lowney | Recommend changes (see comments field) | This needs more specific examples. Examples of structural navigation and how they might be configurable could include: (a) The user can bring up the browser's Find dialog and telling it to search for the next image, and then being able to press keys to move to the next or previous images, and the configurable aspect means they can do the same for other element types beyond just images; (b) The user can have displayed a pane showing an interactive outline of the document's headings, in which the user can activate a heading in order to move focus to the corresponding heading in the main document pane, and which the user can configure to display all headings, or only h1 through h3, etc. |
Jim Allan | Accept the proposal | |
Jan Richards | The proposal needs more discussion (see comments field) | I think this used to refer to the elements that could be navigated to and helped ground the 2.7.5 requirement. Is the term " Set of Important Elements" attached to anything anymore? |
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
w3c/wbs-design
or
by mail to sysreq
.