w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire UAWG Survey for 27 October 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-10-26 to 2011-11-11.
5 answers have been received.
Jump to results for question:
- X.X Navigation marks
- 1.4.1 Configure Text:
- 1.4.2 Preserving Size Distinctions
- 1.4.3 (New) Bounding Container Adjustment
- 1.4.4 (New) Element level access to configure text
- 1.4.5 (New) Access to Typography
- 1.4.6 (New) Access to layout
1. X.X Navigation marks
X.X Navigation marks
The user can mark locations in a webpage and then navigate back to the
marked locations using keyboard shortcuts. A navigation mark will remain
in the same place whether or not the page is changed, e.g. zoom in/out,
font size changed, style sheets applied. The user can specify whether a
navigation mark disappears after a session or is persistent across
sessions.
(There may be different types of navigation marks. The user can view a timeline of navigation marks. The user can organize and share navigation marks.)
Intent of success criterion X.X:
Low vision users who have relatively small screen areas waste a lot of
time scrolling back and forth between screen elements. Hands-free-speech
users are especially prone to voice fatigue or injury when carrying out
tasks that require oft-repeated commands like page down and page up.
Both groups also find themselves doing extra reorientation in navigation
when the focus changes unexpectedly. This can happen when a page views
zoomed or a font size is changed. Navigation marks would enable both
types of users to navigate more efficiently despite these issues.
Examples of Success Criterion X.X:
- Nina is a low vision user PLACEHOLDER
- Sam is a magazine editor who has trouble using the keyboard and mouse
and uses hands-free speech recognition control his computer. He writes
his stories using a Web editor and often pieces together material from
several different sources. Using navigation marks he can say far fewer
navigation commands, which allows him to work longer without overtaxing
his voice.
- Mickey has a head injury which affects his memory and concentration.
He finds it difficult to navigate pages on the Web. Using navigation
marks allows him to navigate more efficiently, which allows him to do
more work.
Related Resources for Success Criterion X.X:
PLACEHOLDER
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | 1 |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal | 4 |
Details
| Responder | X.X Navigation marks | Comments on Navigation Marks |
|---|---|---|
| Markku Hakkinen | Suggest the following changes to the proposal | Not changes, just questions: I like the concept, but I am confused about the process of marking and what exactly is being marked. Is a Nav Mark: a) the current view port position independent of focus location b) the current view port containing the active element with focus c) the current position of the pointing device (for mouse users), and, optionally, the element it is pointing to d) position in the audio stream of a non-visual rendering of the page content, positioned at containing_element + time_offset e) the start position of the current element containing the audio being rendered f) none of the above g) some of the above h) all of the above There may be other markings. For visual recall of nav marks, how is the nav mark positioned in the display? Is the viewport returned to the exact same position as when the mark was made? Is it centered on the display vertically? When moving between nav marks, does focus follow to the first active element in the new view port position (which might be the nav mark itself, but doesn't have to be). Should nav marks belimited to focusable elements? |
| Kimberly Patch | Agree with the proposal | placeholders need to be filled at |
| Jan Richards | Suggest the following changes to the proposal | At the moment it reads like a specific feature rather than a functional requirement, perhaps: X.X Navigation marks: The user can mark locations in web content to which direct navigation is then possible. BTW: What level is being sought? |
| Kelly Ford | Suggest the following changes to the proposal | This probably needs to be separated into a couple SC. The concept is fine in general and interestingly, a couple screen readers have this functionality today. But things like sharing and timelines seem like a lower priority. |
| Greg Lowney | Suggest the following changes to the proposal | It's a nice idea but I think both the SC, Intent and Examples need to provide more guidance before they can be accepted. For example, some things to think about include: (a) if setting up a navigation mark and its associated hotkey is a lot of work, the purpose is defeated; (b) if, in order to simplify both the UI and the implementation, the user agent supports exactly two user-definable navigation marks, does that fulfill the goals?; (c) if caret browsing is off, what point would you expect the bookmark to be associated with? (d) when the number of navigation marks grows to even small number it may quickly tax most users memories and make it difficult to avoid conflicting with other keyboard shortcuts, so wouldn't it be worthwhile to recommend providing a menu of defined navigation marks? (e) are navigation mark sufficiently different from existing bookmark mechanisms, particularly if persistent, to warrant a new concept? (f) what do you expect to happen if the content of the page changes between or during sessions? (g) would you expect navigation marks to be based on some character or word offset, such as the 19th word in the 27th paragraph in the document, or on existing anchors and headings, etc.? Etc. In general it is very helpful to, almost as a though experiment, describe possible UI, the user's workflow, and results. |
2. 1.4.1 Configure Text:
from the email from Wayne
1.4.1 Configure Text:
The user can globally set the following characteristics of visually
rendered text content, overriding any specified by the author or user
agent defaults: (Level A)
(a) text scale (i.e. the general size of text) ,
(b) font family, and
(c) text color (i.e. foreground and background).
(d) ...NEW... Spacing for inter-line and inter-letter. [To address
tracking and crowding. This is a level A access property. Without
spacing adjustments many visual readers with low vision cannot finish
documents]
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | 1 |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | 1 |
| Suggest the following changes to the proposal | 3 |
Details
| Responder | 1.4.1 Configure Text: | Comments on 1.4.1 |
|---|---|---|
| Markku Hakkinen | Suggest the following changes to the proposal | (d) inter-line and inter-character spacing. Question: does this have any implication for other languages, such as Arabic, Hindi, Chinese, Japanese, Thai, etc? What about Ruby Text and vertical presentation? |
| Kimberly Patch | Agree with the proposal | |
| Jan Richards | Suggest the following changes to the proposal | (d) line spacing, and (e) character spacing |
| Kelly Ford | Neutral, will accept consensus of the group | |
| Greg Lowney | Suggest the following changes to the proposal | I'm fine with the addition, although I'd rephrase it more like "Interline and letter-spacing" or even "spacing between characters and lines". However, re the existing portion of the SC: a) Are the phrases "text scale" and "the general size of text" clear enough, or are they vague as to whether it means specifying a single size vs. specifying a magnification level? b) Should it say "can set any or all of the following characteristics"? That is, if the user agent provides one checkbox that turns off all author and default styling, allowing the user to specify only one set of text attributes that would be applied to everything--overriding both colors, fonts, sizes, etc.--would that be OK? Or the benefit of allowing the user to choose to independently override color, font, and or size valuable enough that we want to craft independence into the SC? |
3. 1.4.2 Preserving Size Distinctions
from the email from Wayne
The user can specify whether or not distinctions in the size of rendered text are preserved when that text is rescaled (e.g. headers continue to be larger than body text). [NEW] When size distinctions are not preserved then the user can choose alternative font family, change color (foreground, background) and/or border (style and color).(Level A)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | 1 |
| Disagree with the proposal | 2 |
| Neutral, will accept consensus of the group | 1 |
| Suggest the following changes to the proposal | 1 |
Details
| Responder | 1.4.2 Preserving Size Distinctions | Comments on 1.4.2 |
|---|---|---|
| Markku Hakkinen | Suggest the following changes to the proposal | If size distinctions are not preserved then the user can choose alternative font families, change color (foreground, background) and/or border (style and color).(Level A) |
| Kimberly Patch | Agree with the proposal | |
| Jan Richards | Disagree with the proposal | Sounds like it should be a new SC rather than overloading this one |
| Kelly Ford | Neutral, will accept consensus of the group | |
| Greg Lowney | Disagree with the proposal | I think the new sentence (with the exception of border) is already covered by 1.4.1 which says the user can always override author formatting and specify those attributes. If border is important it should be added to 1.4.1 instead of here. |
4. 1.4.3 (New) Bounding Container Adjustment
from the email from Wayne
1.4.3 (New) Bounding Container Adjustment
When the user adjusts the text configuration then elements that contain
text must adjust height so that the text is visible and the selected
line spacing is preserved. In addition in case of horizontal overflow,
the user can choose to word-wrap on non-word breaks. This also applies
to element level changes in 1.4.4. (Level A)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | 2 |
| Disagree with the proposal | 1 |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal | 2 |
Details
| Responder | 1.4.3 (New) Bounding Container Adjustment | Comments on 1.4.3 |
|---|---|---|
| Markku Hakkinen | Suggest the following changes to the proposal | When the user adjusts the text configuration, the user agent must adjust the height of elements containing text to avoid overflow and maintain visibility of the original content. In case of horizontal overflow, the user can choose to word-wrap on non-word breaks. This also applies to element level changes in 1.4.4. (Level A) QUESTION: In fixed layouts, is vertical scrolling allowed? |
| Kimberly Patch | Agree with the proposal | |
| Jan Richards | Agree with the proposal | I did a quick scan of UAAG2 and it didn't appear to be a repeat. |
| Kelly Ford | Suggest the following changes to the proposal | A SC should not say it also applies to another SC. |
| Greg Lowney | Disagree with the proposal | The whole topic of handling cases where content overflows the width and or height of a bounding element is very complicated, and needs more than just this proposed SC to be handled well. This should not be an "always on" requirement. As worded it could be read as preventing interline spacing from scaling up when text size is changed (e.g. "selected line spacing is preserved" at 6 pixels even when text enlarged to 60 pt). "So that the text is visible" is unclear. "Selected line spacing" is unclear; does it mean line spacing of selected text, or line spacing specified by the user--but is the user required to specify it? |
5. 1.4.4 (New) Element level access to configure text
from the email from Wayne
1.4.4 (New) Element level access to configure text
The user can set the following characteristics of visually rendered text
content at the element level, overriding any specified by the author or
user agent defaults: (Level AA)
(a) text scale (i.e. the general size of text) ,
(b) font family, and
(c) text color (i.e. foreground and background).
(d) ...NEW... Spacing for inter-line and inter-letter. [To address
tracking and crowding. This is a level A access property. Without
spacing adjustments many visual readers with low vision cannot finish
documents]
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | 2 |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | 2 |
| Suggest the following changes to the proposal | 1 |
Details
| Responder | 1.4.4 (New) Element level access to configure text | Comments on 1.4.4 |
|---|---|---|
| Markku Hakkinen | Neutral, will accept consensus of the group | QUESTIONS: Does this mean adjusting, in one place in the UA, the appearance of all H1's, all P's, etc. OR does it mean selecting any element containing text in the current document and specifically altering the appearance of that instance of the Element? Should be specific. change: (d) inter-line and inter-character spacing. |
| Kimberly Patch | Agree with the proposal | |
| Jan Richards | Agree with the proposal | |
| Kelly Ford | Neutral, will accept consensus of the group | |
| Greg Lowney | Suggest the following changes to the proposal | The following questions generally apply to the proposals for 1.4.4 through 1.4.6: How would you implement this for SVG, where the rest of the content does not reflow or adjust when another portion changes? Are there any web technologies that inherently offer less formatting options than HTML with CSS? How does this apply to PNG (images), WebCGM (non-stylable), or a browser rendering a plain text document that lacks internal markup? Should this imply the ability for the user to split elements into multiple peers or sub-elements, such as selecting and affecting only a range of text? Is it useful enough without it, even though it would be severely limited by documents that have lots of unstructured content? For this one, I can imagine a desktop browser adding a Format menu similar to that in word processors? Does it have to guess which nested block- or span-level element the formatting should be applied to? (Word processors typically have formatting for paragraphs, spans, and images, but in HTML things get more complicated.) |
6. 1.4.5 (New) Access to Typography
from the email from Wayne
1.4.5 (New) Access to Typography
The user can change the style of every text element to an extent
equivalent to the style range offered by HTML with CSS. (Level AAA)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | 1 |
| Disagree with the proposal | 1 |
| Neutral, will accept consensus of the group | 1 |
| Suggest the following changes to the proposal | 2 |
Details
| Responder | 1.4.5 (New) Access to Typography | Comments on 1.4.5 |
|---|---|---|
| Markku Hakkinen | Neutral, will accept consensus of the group | Does this mean a UA dialog (or wizard) that allows defining the visual styles of type without having to know CSS? I think without being specific, the easy way out for the UA developer is to say you can do this with a user CSS. |
| Kimberly Patch | Agree with the proposal | |
| Jan Richards | Suggest the following changes to the proposal | Wording is drafty, but I like the idea. I would like to see this dealt with together with user style sheets since that would seem to be a technique of this. |
| Kelly Ford | Disagree with the proposal | This is not clear enough. |
| Greg Lowney | Suggest the following changes to the proposal | See comments on 1.4.4. Given the full range of CSS stylings, can you propose UI for this that is easy enough for most users? This is possible using the Firebug extension for Firefox, but only for the most technically savvy users who know HTML and CSS; is that sufficient? |
7. 1.4.6 (New) Access to layout
from the email from Wayne
1.4.6 (New) Access to layout The user can change the layout of every element to an extent equivalent to the style range offered by HTML with CSS. (Level AAA)
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | 1 |
| Disagree with the proposal | 1 |
| Neutral, will accept consensus of the group | 1 |
| Suggest the following changes to the proposal | 2 |
Details
| Responder | 1.4.6 (New) Access to layout | Comments on 1.4.6 |
|---|---|---|
| Markku Hakkinen | Neutral, will accept consensus of the group | Does this mean a UA dialog (or wizard) that allows defining the visual styles of type without having to know CSS? I think without being specific, the easy way out for the UA developer is to say you can do this with a user CSS. |
| Kimberly Patch | Agree with the proposal | |
| Jan Richards | Suggest the following changes to the proposal | Same comment as above. |
| Kelly Ford | Disagree with the proposal | This is not clear enough. |
| Greg Lowney | Suggest the following changes to the proposal | See comments on 1.4.4. Given the full range of CSS stylings, can you propose UI for this that is easy enough for most users? This is possible using the Firebug extension for Firefox, but only for the most technically savvy users who know HTML and CSS; is that sufficient? |
More details on responses
- Markku Hakkinen: last responded on 26, October 2011 at 19:13 (UTC)
- Kimberly Patch: last responded on 26, October 2011 at 20:01 (UTC)
- Jan Richards: last responded on 27, October 2011 at 03:13 (UTC)
- Kelly Ford: last responded on 27, October 2011 at 16:15 (UTC)
- Greg Lowney: last responded on 27, October 2011 at 17:07 (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