W3C WBS Home

Results of Questionnaire UAWG Survey for 13 Aug

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 2009-08-12 to 2009-08-28.

7 answers have been received.

Jump to results for question:

  1. 4.6 Search vs Find
  2. Find in Media
  3. What if no find function?
  4. 4.6.1 Search Rendered Content:
  5. 4.6.2 Search Forward and Backward:
  6. 4.6.3 Match Found:
  7. 4.6.4 Alert on No Match:
  8. 4.6.5 Case Insensitive:
  9. 4.6.6 Advanced Search:

1. 4.6 Search vs Find

From a proposal from Simon.

Guideline 4.6 Provide Text Search

Proposed

Searching suggests something we do over many documents - find is some thing we do inside a document - although I realize find is what we do to action the searching. Changing "search" to "find" for GL 4.6 title and all success criteria in GL 4.6

Summary

ChoiceAll responders
Results
Accept the proposal 3
Recommend changes (see comments field)
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group 4

Details

Responder 4.6 Search vs FindComments
Simon Harper Accept the proposal
Markku Hakkinen Neutral - will accept the consensus of the group
David Poehlman Accept the proposal
Kelly Ford Neutral - will accept the consensus of the group I think this is fine the way it is but if the group thinks differently, I can live with the change. Search doesn't necessarily imply multiple docuemnts and for alnguage style text search versus text find sounds better to me.
Kimberly Patch Neutral - will accept the consensus of the group
Greg Lowney Neutral - will accept the consensus of the group I don't feel strongly about it.

I agree that the term "search" as in "search engine" or the Search command on the Windows Start menu is most commonly used in the context of locating something across multiple places, while both the Windows and Mac operating environments standardize on the term "Find" for locating a text string in the current document.

Yet, I think "Search" works better as a stand-alone verb than "Find". for example, "Search rendered content" seems simpler and clearer than "Find in rendered content" or "Find text in rendered content".

Yet, changing it throughout 4.6 would make some working more awkward (e.g. "
Jeanne F Spellman Accept the proposal

2. Find in Media

From a proposal from Simon.

Clarification

Question

GL 4.6 is about text content - but does this mean captions in multimedia - and if so is it the player or the browsers responsibility to offer this functionality?

Summary

ChoiceAll responders
Results
Yes 3
No
Depends 2

(2 responses didn't contain an answer to this question)

Details

Responder Find in MediaComments
Simon Harper Depends
Markku Hakkinen Yes With HTML5 video and audio are integrated, and IMO, any caption/transcript text is in effect part of the text context of the page. It should be available via DOM, and in reality, it is unclear when the browser will be by default handling the display of any caption text, or whether it will be up to the author to define via scripting how the text is to be displayed. I expect that if the browser's video element has a default display mode for captions, the author can over-ride and craft their own caption display using scripting and css.
David Poehlman Depends if the content is offered in the browser, it's the browser's responsibility. if a player is envolved than the player holds the responsibility but I'm not sure how far we can go with telling players what they should do.
Kelly Ford Yes I think it is the agent showing the captions. If you are getting the captions from aplugin, the search should be part of that. If the user agent/browser is doing the video captions then that progrma should be allowing for the search of same.
Kimberly Patch Browser could offer UI consistency.
Greg Lowney Yes 4.6.1 requires searching "text and text alternatives". Wouldn't that already include both closed and open captions?

In best practices we should probably recommend that UA offer the user an option to search through either just rendered content or through both rendered content and its alternative representations (e.g. alt text, captions). This could help with the problem of users reacting negatively when results of a text search seem to have nothing to do with the search string, e.g. being confused when the search highlights an image that seems to have nothing to do with their search query, not realizing the string appears in the image's alt text.
Jeanne F Spellman

3. What if no find function?

From a proposal from Simon.

Question

If search / find is not included in the UA functionality - does a UA need to add it specifically to meet our guidelines?

Summary

ChoiceAll responders
Results
Yes 5
No
Depends 2

Details

Responder What if no find function?Comments
Simon Harper Yes
Markku Hakkinen Yes Text search is an essential component to support accessibility, particularly for efficient content reading in non-visual contexts. I can see that in mobile device browsers, text search is typically not included (or at least not evident).
David Poehlman Depends if we have one implementation, then yes.
Kelly Ford Yes To the extent we believe find/search is an accessibility requirement, yes the UA would need to add this.
Kimberly Patch Yes
Greg Lowney Depends Currently text search is Level AA. Are you recommending promoting it to Level A?
Jeanne F Spellman Yes

4. 4.6.1 Search Rendered Content:

From a proposal from Simon.

Current

4.6.1 Search Rendered Content: The user can perform a search within rendered (e.g., not hidden with a style) content for text and text alternatives for a sequence of characters from the document character set. (Level AA)

Proposed

4.6.1 Search Rendered: The user can perform a search within rendered content (e.g., not hidden with a style) for text and text alternatives for a sequence of characters from the document character set. (Level A)

Summary

ChoiceAll responders
Results
Accept the proposal 7
Recommend changes (see comments field)
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder 4.6.1 Search Rendered Content:Comments
Simon Harper Accept the proposal
Markku Hakkinen Accept the proposal
David Poehlman Accept the proposal
Kelly Ford Accept the proposal
Kimberly Patch Accept the proposal
Greg Lowney Accept the proposal This agrees with my earlier comment #88. "(Re 4.6.1) Why is Searching Level AA?: I assume there is a good reason that Search Rendered Content is Level AA instead of Level A, but it seems at first consideration that it would merit Level A, both because it's easy and because it's almost universally implemented (at least in Web browsers, email clients, and similar user agents). If the reason is that it's more difficult or less common to search text alternatives as well as rendered text, consider splitting it into two separate success criteria, one at Level A for searching rendered content, and the other at Level AA for searching rendered content AND text alternatives. (Priority: 3 Low) (Type: Expand)"
Jeanne F Spellman Accept the proposal

5. 4.6.2 Search Forward and Backward:

From a proposal from Simon.

Current

4.6.2 Search Forward and Backward: The user has the option of searching forward or backward from any selected or focused location in content. (Level AA)

Proposed

4.6.2 Search Direction: (Level A):
(a) direction: The user has the option of searching forward or backward from any selected or focused location in content
(b) notification: the user is notified of changes in search direction; and when the search reaches the upper or lower extent of the content based on the search direction.

Summary

ChoiceAll responders
Results
Accept the proposal 3
Recommend changes (see comments field)
The proposal needs more discussion (see comments field) 3
Disagree with the proposal
Neutral - will accept the consensus of the group

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

Details

Responder 4.6.2 Search Forward and Backward:Comments
Simon Harper Accept the proposal
Markku Hakkinen The proposal needs more discussion (see comments field) Not convinced this is A... probably AA.
David Poehlman The proposal needs more discussion (see comments field) there is also a need for a rap function and a find again function.
Kelly Ford Accept the proposal
Kimberly Patch Accept the proposal
Greg Lowney The proposal needs more discussion (see comments field) I don't agree with shoehorning these three separate (albeit related) things into a single, compound item. In addition, the current wording seems unnecessarily confusing.

I don't understand the need for notifying the user when the direction changes, as I'm not aware of any cases where it changes except by direct user request.

4.6.4 already requires the user be notified when no more matches are found in the current search direction, so I don't understand the third proposed clause.

Jeanne F Spellman

6. 4.6.3 Match Found:

From a proposal from Simon.

Current

4.6.3 Match Found: When there is a match, both of the following are true (Level AA):
* (a) move: the viewport moves so that the matched text content is at least partially within it, and
* (b) search again: the user can search for the next instance of the text from the location of the match.

Proposed

4.6.3 Match Found: When there is a match, the following are true (Level A):
(a) notification: the user is alerted
(b) move: the viewport moves so that the matched text content is at least partially within it,
(c) search again: the user can search for the next instance of the text from the location of the match.

Summary

ChoiceAll responders
Results
Accept the proposal 2
Recommend changes (see comments field)
The proposal needs more discussion (see comments field) 3
Disagree with the proposal
Neutral - will accept the consensus of the group 1

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

Details

Responder 4.6.3 Match Found:Comments
Simon Harper Accept the proposal
Markku Hakkinen Accept the proposal
David Poehlman The proposal needs more discussion (see comments field) I think the move focus needs to be settable. I like the alert idea but search again needs to above I think.
Kelly Ford Neutral - will accept the consensus of the group
Kimberly Patch The proposal needs more discussion (see comments field) What happens when the user does a search, then moves the cursor, then continues the search expecting to search from the cursor location?
Greg Lowney The proposal needs more discussion (see comments field) This raises a number of issues. I'm not sure Search Again is needed. Do we need to explicitly mention: (a) that the found text should be selected or, if selection is not supported, highlighted; (b) that one can search from the end of the current selection; etc.?
Jeanne F Spellman

7. 4.6.4 Alert on No Match:

From a proposal from Simon.

Current

4.6.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 AA)

Proposed

4.6.4 No Match Found: When there is no match, the following is true (Level A):
(a) notification: the user is alerted

Summary

ChoiceAll responders
Results
Accept the proposal 3
Recommend changes (see comments field) 1
The proposal needs more discussion (see comments field)
Disagree with the proposal 1
Neutral - will accept the consensus of the group 1

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

Details

Responder 4.6.4 Alert on No Match:Comments
Simon Harper Accept the proposal
Markku Hakkinen Recommend changes (see comments field) 4.6.4 No Match Found: When there is no match, the following is true (Level A):
(a) notification: the user is notified that no match was found.

comment: the problem here is indicating the context of the search. Is it not found in the entire document, or simply not found from the search start point to the end of the document. This should issue should be addressed.
David Poehlman Accept the proposal focus needs to be placed at the point where the search started.
Kelly Ford Neutral - will accept the consensus of the group
Kimberly Patch Accept the proposal
Greg Lowney Disagree with the proposal (a) I don't agree with creating an ordered list with only one item.
(b) I don't agree with removing the requirement to notify the user before the search wraps.
Jeanne F Spellman

8. 4.6.5 Case Insensitive:

From a proposal from Simon.

Current

4.6.5 Case Insensitive: There is a case-insensitive search option. (Level AA)

Proposed

4.6.5 Case Sensitivity: There is a case sensitive and case- insensitive search option. (Level A)

Summary

ChoiceAll responders
Results
Accept the proposal 3
Recommend changes (see comments field) 1
The proposal needs more discussion (see comments field)
Disagree with the proposal 1
Neutral - will accept the consensus of the group 1

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

Details

Responder 4.6.5 Case Insensitive: Comments
Simon Harper Accept the proposal
Markku Hakkinen Neutral - will accept the consensus of the group
David Poehlman Accept the proposal if there is a case sensative search option, there must be an insensative oe but not necessarily for the transverse.
Kelly Ford Disagree with the proposal I'm not convinced this rises to a level A requirement.
Kimberly Patch Accept the proposal
Greg Lowney Recommend changes (see comments field) (a) I'm not convinced we should promote this to Level A.

(b) Might reword it to be more consistent with other items in the document, such as "The user has to option to..."
Jeanne F Spellman

9. 4.6.6 Advanced Search:

From a proposal from Simon.

No Current

Proposed

4.6.6 Advanced Search: If the user agent provides an advanced search facility, it is fully accessible. (Level AA)

Summary

ChoiceAll responders
Results
Accept the proposal 3
Recommend changes (see comments field)
The proposal needs more discussion (see comments field) 1
Disagree with the proposal 1
Neutral - will accept the consensus of the group 1

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

Details

Responder 4.6.6 Advanced Search:Comments
Simon Harper Accept the proposal
Markku Hakkinen Neutral - will accept the consensus of the group
David Poehlman Accept the proposal a lot of the search functionality above can be put here if it exists.
Kelly Ford Disagree with the proposal What's the point of this? If the user agent provides any functionality, it is it expected to be accessible to the extent that the UA wants to comply with guidelines so why would this advanced search be called out as a separate item?
Kimberly Patch Accept the proposal
Greg Lowney The proposal needs more discussion (see comments field) I don't see the advantage of something so general. Aren't ALL facilities already supposed to be fully accessible?
Jeanne F Spellman

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Judy Brewer <jbrewer@w3.org>
  2. Jim Allan <jimallan@tsbvi.edu>
  3. Jan Richards <jrichards@ocadu.ca>
  4. Eric Hansen <ehansen@ets.org>
  5. Wayne Dick <wayneedick@gmail.com>
  6. Peter Parente <pparent@us.ibm.com>
  7. Simon Pieters <simonp@opera.com>
  8. Takeshi Kurosawa <kurosawa-takeshi@mitsue.co.jp>
  9. Alan Cantor <alan@cantoraccess.com>
  10. he wen <rockywen@tencent.com>
  11. Henny Swan <hswan@paciellogroup.com>
  12. Shaohang Yang <shaohang.ysh@alibaba-inc.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)