W3C WBS Home

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:

  1. 2.4.1 Find
  2. 2.4.2 Find Direction
  3. 2.4.3 Match Found
  4. 2.4.4 Alert on No Match
  5. 2.4.5 Advanced Find
  6. 2.5.3 Location in Hierarchy
  7. 2.5.5 Access to Relationships which Aid Navigation
  8. 2.5.7 Configure Elements for Structural Navigation
  9. 2.6.1 List event handlers
  10. 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

ChoiceAll responders
Results
Yes, it is ok as is 5
No, more discussion needed. See comments 3

Details

Responder 2.4.1 FindComments 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

ChoiceAll responders
Results
Yes, it is ok as is 6
No, more discussion needed. See comments 1

(1 response didn't contain an answer to this question)

Details

Responder 2.4.2 Find DirectionComments 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

ChoiceAll responders
Results
Yes, it is ok as is 3
No, more discussion needed. See comments 4

(1 response didn't contain an answer to this question)

Details

Responder 2.4.3 Match FoundComments 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

ChoiceAll responders
Results
Yes, it is ok as is 5
No, more discussion needed. See comments 3

Details

Responder 2.4.4 Alert on No MatchComments 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

ChoiceAll responders
Results
Yes, it is ok as is 3
No, more discussion needed. See comments 5

Details

Responder 2.4.5 Advanced FindComments 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

ChoiceAll responders
Results
Yes, it is ok as is 2
No, more discussion needed. See comments 6

Details

Responder 2.5.3 Location in HierarchyComments 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

ChoiceAll 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 NavigationComments 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

ChoiceAll 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 NavigationComments 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

ChoiceAll responders
Results
Yes, it is ok as is 5
No, more discussion needed. See comments 3

Details

Responder 2.6.1 List event handlersComments 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

ChoiceAll responders
Results
Yes, it is ok as is 6
No, more discussion needed. See comments 2

Details

Responder 2.6.2 Activate any event handlerComments 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

Non-responders

The following persons have not answered the questionnaire:

  1. Judy Brewer <jbrewer@w3.org>
  2. Eric Hansen <ehansen@ets.org>
  3. Wayne Dick <wayneedick@gmail.com>
  4. Peter Parente <pparent@us.ibm.com>
  5. Simon Pieters <simonp@opera.com>
  6. Takeshi Kurosawa <kurosawa-takeshi@mitsue.co.jp>
  7. Alan Cantor <alan@cantoraccess.com>
  8. he wen <rockywen@tencent.com>
  9. Henny Swan <hswan@paciellogroup.com>

Send an email to all the non-responders.


Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire


Maintained by Laurent Carcone, from a development by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.127 2015-02-04 08:52:34 carcone Exp $. Please send bug reports and request for enhancements to lcarcone@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)