w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
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:
- 4.6 Search vs Find
- Find in Media
- What if no find function?
- 4.6.1 Search Rendered Content:
- 4.6.2 Search Forward and Backward:
- 4.6.3 Match Found:
- 4.6.4 Alert on No Match:
- 4.6.5 Case Insensitive:
- 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
| Choice | All 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 Find | Comments |
|---|---|---|
| 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
| Choice | All responders |
|---|---|
| Results | |
| Yes | 3 |
| No | |
| Depends | 2 |
Details
| Responder | Find in Media | Comments |
|---|---|---|
| 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
| Choice | All 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
| Choice | All 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
| Choice | All 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 |
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
| Choice | All 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 |
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
| Choice | All 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 |
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
| Choice | All 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 |
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
| Choice | All 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 |
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
- Simon Harper: last responded on 13, August 2009 at 08:16 (UTC)
- Markku Hakkinen: last responded on 13, August 2009 at 09:12 (UTC)
- David Poehlman: last responded on 13, August 2009 at 15:27 (UTC)
- Kelly Ford: last responded on 13, August 2009 at 15:52 (UTC)
- Kimberly Patch: last responded on 20, August 2009 at 15:54 (UTC)
- Greg Lowney: last responded on 20, August 2009 at 17:53 (UTC)
- Jeanne F Spellman: last responded on 20, August 2009 at 17:53 (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