w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire UAWG Survey for 17 November 2011
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-11-16 to 2011-12-02.
8 answers have been received.
Jump to results for question:
- 2.4.1 Find
- 2.4.2 Find Direction
- 2.4.3 Match Found
- 2.4.4 Alert on No Match
- 2.4.5 Advanced Find
- 2.5.3 Location in Hierarchy
- 2.5.5 Access to Relationships which Aid Navigation
- 2.5.7 Configure Elements for Structural Navigation
- 2.6.1 List event handlers
- 2.6.2 Activate any event handler
1. 2.4.1 Find
2.4.1 Find:
The user can perform a search within rendered content (e.g. not hidden with a style), including text alternatives, for any sequence of characters from the document character set. (Level A)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ok as is | 5 |
| No, more discussion needed. See comments | 3 |
Details
| Responder | 2.4.1 Find | Comments 2.4.1 |
|---|---|---|
| Markku Hakkinen | Yes, it is ok as is | |
| Jan Richards | Yes, it is ok as is | |
| Simon Harper | No, more discussion needed. See comments | OK but I'm not sure about the style - of the hidden html5 property... Hidden by style is ambiguous, it could just mean placed off the viewport, small text, text hidden by colour. etc |
| Greg Lowney | No, more discussion needed. See comments | 1. Might the phrase "any sequence of characters from the document character set" require the ability to search for characters such as newline, tab, and non-breaking space? Is that the intention? (Interestingly, Firefox 3, Chrome 15 and Safari 5 treat non-breaking spaces in Find as just normal spaces, whereas Internet Explorer 9 won't ever find a match for a non-breaking spaces. And while newline and tab characters are generally treated as generic whitespace in current versions of HTML, they may be respected and differentiated in PRE elements and may have other uses in the future or in other document formats.) 2. The glossary definition of "document character set" reads "The internal representation of data in the source content by a user agent." To me that definition would include the data structure of the DOM, which I don't think is the intention. 3. Searching within alternative content ("text alternatives") is covered by 2.4.5 Advanced Find; it shouldn't be in both places, and I think it's more appropriate for advanced find (Level AA) than basic find (Level A). |
| Jeanne F Spellman | Yes, it is ok as is | |
| Kelly Ford | Yes, it is ok as is | It would be good to have an example that gives our idea of how the user agent should handle cases where the text is from an alternative. For example, if the text is in a title tag, what should the user agent do? |
| Jim Allan | No, more discussion needed. See comments | in the example we will need to provide some guidance as to how the found alternative text is to be revealed to the user. For images with alternative text the image should be highlighted. Sometimes content is styled to be off screen (out of viewport) but not 'hidden' this content should be revealed to the user. For example, if a <label> is styled to be off screen, when searching for the label text the form control should be highlighted. With collapsed content or menus, the collapsed content/menu should expand to reveal the content and the proper terms highlighted. Will this cover title? though by spec it is advisory not alternative content, many authors (including myself) use title on form fields that have no on screen prompting. |
| Kimberly Patch | Yes, it is ok as is |
2. 2.4.2 Find Direction
2.4.2 Find Direction
The user can search forward or backward from the focused location in content. The user is notified of changes in search direction. The user is notified when the search reaches the upper or lower extent of the content based on the search direction. (Level A)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ok as is | 6 |
| No, more discussion needed. See comments | 1 |
Details
| Responder | 2.4.2 Find Direction | Comments 2.4.2 |
|---|---|---|
| Markku Hakkinen | Yes, it is ok as is | |
| Jan Richards | Yes, it is ok as is | |
| Simon Harper | Yes, it is ok as is | |
| Greg Lowney | Recommendation: 2.4.2 Find Direction: The user can search forward or backward in rendered content. (Level A) Rationale: 1. It seems this SC contains several very separate things related to search, so I question whether it makes sense to lump them together. If we do keep them together, they might be more readable if combined into a single sentence such as "The user can search forward or backward from the focused location in content, be notified of changes in search direction and when the search reaches the upper or lower extent of the content based on the search direction." 2. It should say that the user *can* request these notifications, rather than requiring notification in all cases as is mandated by "the user is notified". Can we use the wording we're using elsewhere of "the user can", or does that get misleading with "be notified" because as it sound as if the choice belongs to the user agent rather than to the user? 3. I'm not sure we want to restrict Find to only being from the "focused location", presumably meaning the keyboard focus location (as opposed to focus location for other input devices, such as the pointer focus or a remote keyboard focus in the case of multiple users). How many users have been confused and tasks messed up because Find started from the keyboard focus location rather than from the user's point of regard? (Example, you search once, then manually scroll the window down many screenfuls, then search again and it does not start from where you expected.) I think that if a user agent wants to define search as being from the point of regard, we should let them. Similarly, it is conceivable that a user agent might have a good reason not to move the keyboard focus to the search results, yet would probably still want the next search to continue from there. 4. What is meant by "The user is notified of changes in search direction"? Are there known cases where search direction changes other than on user request? 5. The notification on wrapping is covered by 2.4.4 Alert on No Match so isn't needed here. See my comments to that one below. | |
| Jeanne F Spellman | Yes, it is ok as is | |
| Kelly Ford | No, more discussion needed. See comments | Wording is too long. And this really asks for three things. |
| Jim Allan | Yes, it is ok as is | |
| Kimberly Patch | Yes, it is ok as is |
3. 2.4.3 Match Found
2.4.3 Match Found
When there is a match, the user is alerted and the viewport's content moves so that the matched text content is at least partially within it. The user can search for the next instance of the text from the location of the match. (Level A)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ok as is | 3 |
| No, more discussion needed. See comments | 4 |
Details
| Responder | 2.4.3 Match Found | Comments 2.4.3 |
|---|---|---|
| Markku Hakkinen | No, more discussion needed. See comments | Only concern relates to matches found in alternate text. For example, in images, how is the matched content indicated (e.g. the image is positioned to and highlighted). For time-based content, such as subtitle or caption tracks, is the time-based content positioned to the frame or sequence containing the text match? What is the play/pause state? |
| Jan Richards | No, more discussion needed. See comments | Is the second sentence needed? |
| Simon Harper | Yes, it is ok as is | |
| Greg Lowney | Recommendation (demonstrating two combinations of phrasing options): 2.4.3 Match Found: When a search operation produces a match, the matched content is highlighted and presented within the visible area of the viewport. The user can search from the location of the match. (Level A) Or 2.4.3 Match Found: When a search operation produces a match, the matched content is highlighted, the viewport is scrolled if necessary so that the matched content is within its visible area, and the user can search from the location of the match. (Level A) 1. Rationale: a. Makes it explicit that this is about a match on a search/find operation. b. There is no reason why this behavior shouldn't also apply to non-text searches, such as Microsoft Word's ability to search for the next graphic or table. c. Removed the word "for the next match" because searches can be for next or previous matches. d. I don't think it necessary to say "the user is alerted", and I certainly would not want to imply that any sort of active notification (e.g. a message box) to be required. In general highlighting the matched content and scrolling the viewport if necessary should be enough. Highlighting of search results does not appear to be required by 1.3.1 Highlighted Items, so we should mention it here. I guess it should be allowed for the user agent to highlight the match by selecting it rather than requiring a separate category of highlights. 2. Could combine the two sentences or leave them separate. | |
| Jeanne F Spellman | No, more discussion needed. See comments | "alerted" sounds too much like a popup box. "notified" would probably be better. It's a nit, so I will go with consensus. |
| Kelly Ford | No, more discussion needed. See comments | What do we mean alerted? |
| Jim Allan | Yes, it is ok as is | |
| Kimberly Patch | Yes, it is ok as is |
4. 2.4.4 Alert on No Match
2.4.4 Alert on No Match
The user is notified when there is no match or after the last match in content (i.e. prior to starting the search over from the beginning of content). (Level A)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ok as is | 5 |
| No, more discussion needed. See comments | 3 |
Details
| Responder | 2.4.4 Alert on No Match | Comments 2.4.4 |
|---|---|---|
| Markku Hakkinen | Yes, it is ok as is | |
| Jan Richards | Yes, it is ok as is | |
| Simon Harper | Yes, it is ok as is | |
| Greg Lowney | No, more discussion needed. See comments | Recommended: 2.4.4 Notification at End of Find: The user can be notified when a search reaches the upper or lower extent of the search range, regardless of whether the search will continue beyond that range or from the other extent. (Level A) 1. Should say "can be notified" or equivalent, allowing it to be a user option, rather than requiring it to be an "always on" behavior as the previous wording required. 2. I adapted the more general wording from 2.4.1 Find, which covered searching up as well as down, and I also replaced the maximum extents of the document with those of the search range, for user agents (such as Microsoft Word) that ask for confirmation before continuing a search beyond the selection or wrapping at the start or end of the document. 3. Editorial, but replaced "the search" with "a search". |
| Jeanne F Spellman | Yes, it is ok as is | |
| Kelly Ford | No, more discussion needed. See comments | Isn't the second part of this already covered in 2.4.2 about search direction? |
| Jim Allan | Yes, it is ok as is | |
| Kimberly Patch | No, more discussion needed. See comments | This might be simpler: The user is notified when there is no match and when starting the search over from the beginning of content. (Level A) |
5. 2.4.5 Advanced Find
2.4.5 Advanced Find
The user agent provides an accessible advanced search facility, with a case-sensitive and case-insensitive search option, and the ability for the user to perform a search within all content (including hidden content and captioning) for text and text alternatives, for any sequence of characters from the document character set. (Level AA)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ok as is | 3 |
| No, more discussion needed. See comments | 5 |
Details
| Responder | 2.4.5 Advanced Find | Comments 2.4.5 |
|---|---|---|
| Markku Hakkinen | No, more discussion needed. See comments | Did 2.4.1 exclude captions? |
| Jan Richards | No, more discussion needed. See comments | Why including hidden content? Maybe this whols SC can go. |
| Simon Harper | Yes, it is ok as is | |
| Greg Lowney | No, more discussion needed. See comments | Recommendation: 2.4.5 Advanced Find: The user can search with a case-sensitivity option and the ability to search all content (including alternative content, hidden content, and captions) for any sequence of characters from the document character set. Or remove the reference to hidden content: 2.4.5 Advanced Find: The user can search with a case-sensitivity option and the ability to search all content (including alternative content and captions) for any sequence of characters from the document character set. 1. Rationale: a. Searching "for text and text alternatives, for any sequence" sounds like an accident, and in particular "*for* text and text alternatives" sounds like it's talking about a means of locating items that have alternative text, rather than locating alternative text that contains a given string. I'd recommend something like "…perform a search within all content (including alternative content, hidden content, and captions) for any sequence…" b. Minor editorial suggestions: "with case-sensitive and case-insensitive search options", or "with a case sensitivity option"; the first commas is not needed and the latter two are not needed after the proposed shortening; leaving out that it's an "accessible advanced search facility", (everything is supposed to meet all of the success criteria in this document, after all); etc. 2. Note my comments to 2.5.1 above, namely: a. Might the phrase "any sequence of characters from the document character set" require the ability to search for characters such as newline, tab, and non-breaking space? (Interestingly, Firefox 3, Chrome 15 and Safari 5 treat non-breaking spaces in Find as just normal spaces, whereas Internet Explorer 9 won't ever find a match for a non-breaking space. And while newline and tab characters are generally treated as generic whitespace in current versions of HTML, they may be respected and differentiated in PRE elements and may have other uses in the future or in other document formats.) b. Also, the glossary definition of "document character set" reads "The internal representation of data in the source content by a user agent." To me that definition would include the data structure of the DOM, which I don't think is the intention. 3. It's hard to picture a good user interface for indicating search results within hidden content, and certainly I doubt any user agents do it today. (I think this is trickier than indicating an element with matching alternative content, which Mark raised as an issue.) Also, content is often hidden for good reason, such as being inappropriate for the current configuration of the page, and searching within it wouldn't be useful. Therefore I'm tempted to recommend removing that portion of the SC. Re Jan's comment, if searching hidden content is removed this still have both case-sensitivity and searching of alternative content which are not in basic search. They could be moved there, promoting them to Level A, although I'm not sure whether they're implemented anywhere, and certainly not widely. |
| Jeanne F Spellman | No, more discussion needed. See comments | Ugh! Do we need to define "accessible"? |
| Kelly Ford | No, more discussion needed. See comments | The word accessible certainly doesn't need to be here. Further, the reader has to work hard to figure out what's different here between this and 2.4.1. This adds things like case, hidden text and such. It needs to be more obvious. |
| Jim Allan | Yes, it is ok as is | |
| Kimberly Patch | Yes, it is ok as is |
6. 2.5.3 Location in Hierarchy
2.5.3 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) .
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ok as is | 2 |
| No, more discussion needed. See comments | 6 |
Details
| Responder | 2.5.3 Location in Hierarchy | Comments 2.4.1 |
|---|---|---|
| Markku Hakkinen | No, more discussion needed. See comments | Why is this A? Maybe better as AA? What are the use cases? |
| Jan Richards | No, more discussion needed. See comments | Too complicated for final wording...why not just remove the big conditional: The user can view the path of nodes leading from the root to the current focussed element. |
| Simon Harper | Yes, it is ok as is | |
| Greg Lowney | No, more discussion needed. See comments | There are outstanding comments in previous surveys, e.g. at http://www.w3.org/2002/09/wbs/36791/20100521/results#xq13. I still find it too unclear to be used as-is. Re Jan's suggested rewrite which would essentially be combining this with 2.5.5 (below), 2.5.3 is currently about about relationships the UA knows about that aren't in the DOM, which makes sense for things like a media player but not for a general-purpose web browser. That's an important difference from 2.5.5, which *is* appropriate for a web browser. |
| Jeanne F Spellman | No, more discussion needed. See comments | Although I remember discussion about this, I took a fresh look at it and realized I hadn't a clue what this meant, or how it would be used. |
| Kelly Ford | No, more discussion needed. See comments | Too confusing, especially for a level a guideline. |
| Jim Allan | Yes, it is ok as is | |
| Kimberly Patch | No, more discussion needed. See comments | This might make it easier to read: ... HTML5 item / itemprop microdata elements). This is required 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). |
7. 2.5.5 Access to Relationships which Aid Navigation
2.5.5 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)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ok as is | 4 |
| No, more discussion needed. See comments | 4 |
Details
| Responder | 2.5.5 Access to Relationships which Aid Navigation | Comments 2.5.5 |
|---|---|---|
| Markku Hakkinen | Yes, it is ok as is | |
| Jan Richards | No, more discussion needed. See comments | So this appears to pretty much duplicate what I just simplified 2.5.3 down to. |
| Simon Harper | Yes, it is ok as is | |
| Greg Lowney | No, more discussion needed. See comments | The SC wording is fine. However, on the conference call of 2011-08-11 we discussed the fact that the SC 1.11.1 and this SC (then 2.5.2, now 2.5.5) were duplicates of each other, although their Intent and Examples were not, and debated which Principle was an appropriate location. I don't see a resolution, but I said then that if it's merely about presenting relationships to the user then 1.11 (Perceivable - Provide element information) seems more appropriate than 2.5 (Operable - Provide structural navigation). I'm not sure that appending "which aid navigation" to the title makes it more appropriate in 2.5, but I'll accept the majority opinion. |
| Jeanne F Spellman | Yes, it is ok as is | |
| Kelly Ford | No, more discussion needed. See comments | Confusing to me. |
| Jim Allan | Yes, it is ok as is | |
| Kimberly Patch | No, more discussion needed. See comments | Copyedit for clarity: change ... content, and the path to ... content and on the path |
8. 2.5.7 Configure Elements for Structural Navigation
2.5.7 Configure Elements for Structural Navigation
The user can independently configure the set of important elements (including element types) for structured navigation and hierarchical/outline view. (Level AAA)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ok as is | 6 |
| No, more discussion needed. See comments | 2 |
Details
| Responder | 2.5.7 Configure Elements for Structural Navigation | Comments 2.5.7 |
|---|---|---|
| Markku Hakkinen | No, more discussion needed. See comments | I don't see this as an AAA. Could be A, and I am thinking that since the text is "Configure Elements for Structural Nav", why include "hierarchical/outline view" as I think it is separate (I am not sure what I agreed to at the f2f). I can see this as A if hierarchical/outline view is moved elsewhere. |
| Jan Richards | Yes, it is ok as is | But can we remove "independently"? |
| Simon Harper | Yes, it is ok as is | |
| Greg Lowney | No, more discussion needed. See comments | Fine except it should be "sets" of important elements. Re Mark's comment I'd be happy to keep them separate. Re Jan's comment, if we keep the two areas combined into a single SC it's important to make it clear that the user should be able to set separate criteria for what elements are included in an outline view (e.g. show only h1 through h3) vs. those that are used for structural navigation (e.g. go to the preceding heading or table heading). |
| Jeanne F Spellman | Yes, it is ok as is | |
| Kelly Ford | Yes, it is ok as is | Yes assuming we've agreed on all these words. |
| Jim Allan | Yes, it is ok as is | |
| Kimberly Patch | Yes, it is ok as is |
9. 2.6.1 List event handlers
2.6.1 List event handlers
The user can, through keyboard input alone, call up a list of input device event handlers explicitly associated with the keyboard focus element. (Level A)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ok as is | 5 |
| No, more discussion needed. See comments | 3 |
Details
| Responder | 2.6.1 List event handlers | Comments 2.6.1 |
|---|---|---|
| Markku Hakkinen | Yes, it is ok as is | |
| Jan Richards | No, more discussion needed. See comments | So this is one that needs to be universalized (e.g. for devices without keyboards) |
| Simon Harper | Yes, it is ok as is | |
| Greg Lowney | Yes, it is ok as is | Re Jan's comment, we would use whatever language we settle on for including keyboards, keyboard interfaces, and keyboard emulators. Of course, saying anything should be doable using a keyboard interface is redundant to the SC that says *everything* must be doable through a keyboard interface; we reiterate it explicitly in some SC, but not in most. I'd be OK removing it. In fact, an interesting thought would be to consider adding a Guideline and success criteria about input devices other than the keyboard, and I just sent a draft to the list. |
| Jeanne F Spellman | Yes, it is ok as is | |
| Kelly Ford | No, more discussion needed. See comments | Not clear. What list, all event handlers, some what. |
| Jim Allan | Yes, it is ok as is | |
| Kimberly Patch | No, more discussion needed. See comments | Here's a start if we want to think about making this language broader to do with touch, etc.: The user can, through a modalality independent interface, call up a list of input device handlers associated with any focus element. |
10. 2.6.2 Activate any event handler
2.6.2 Activate any event handler
The user can, through keyboard input alone, activate any input device event handlers explicitly associated with the keyboard focus element. (Level A)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ok as is | 6 |
| No, more discussion needed. See comments | 2 |
Details
| Responder | 2.6.2 Activate any event handler | Comments 2.6.2 |
|---|---|---|
| Markku Hakkinen | Yes, it is ok as is | |
| Jan Richards | No, more discussion needed. See comments | Also needs to be universalized. |
| Simon Harper | Yes, it is ok as is | |
| Greg Lowney | Yes, it is ok as is | (But I notice that the revisions to 2.6.3 Activate All Event Handlers sent along with these ones in email of 12/2/2009 were not included. Was that intentional or an oversight?) |
| Jeanne F Spellman | Yes, it is ok as is | |
| Kelly Ford | No, more discussion needed. See comments | We've talked about this before. This I don't think it what we actually mean. We are not asking to step throguh each handler necessarily, just achieve the final end result. |
| Jim Allan | Yes, it is ok as is | |
| Kimberly Patch | Yes, it is ok as is | Here's a start if we want to think about making this language broader to do with touch, etc.: The user can, through a modalality independent interface, activate any input device event handler. (Level A) |
More details on responses
- Markku Hakkinen: last responded on 16, November 2011 at 19:18 (UTC)
- Jan Richards: last responded on 17, November 2011 at 03:49 (UTC)
- Simon Harper: last responded on 17, November 2011 at 06:24 (UTC)
- Greg Lowney: last responded on 17, November 2011 at 07:29 (UTC)
- Jeanne F Spellman: last responded on 17, November 2011 at 16:29 (UTC)
- Kelly Ford: last responded on 17, November 2011 at 16:33 (UTC)
- Jim Allan: last responded on 17, November 2011 at 17:04 (UTC)
- Kimberly Patch: last responded on 17, November 2011 at 17:54 (UTC)
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
Report issues
on GitHub project