W3C WBS Home

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:

  1. X.X Navigation marks
  2. 1.4.1 Configure Text:
  3. 1.4.2 Preserving Size Distinctions
  4. 1.4.3 (New) Bounding Container Adjustment
  5. 1.4.4 (New) Element level access to configure text
  6. 1.4.5 (New) Access to Typography
  7. 1.4.6 (New) Access to layout

1. X.X Navigation marks

Kim's email

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

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

ChoiceAll 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

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

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

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

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

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

Non-responders

The following persons have not answered the questionnaire:

  1. Judy Brewer <jbrewer@w3.org>
  2. Jim Allan <jimallan@tsbvi.edu>
  3. Eric Hansen <ehansen@ets.org>
  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. Jeanne F Spellman <jeanne@w3.org>
  9. Simon Harper <simon.harper@manchester.ac.uk>
  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)