w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire UAWG Survey for 17 October 2013
The results of this questionnaire are available to anybody.
This questionnaire was open from 2013-10-16 to 2013-11-01.
7 answers have been received.
Jump to results for question:
- 1.4 Guidelines Notes
- 1.4.1 & 1.4.2 Text Scale change to Text Size
- 1.4.1 IER
- 1.4.2 IER
- 1.4.3 IER
- 1.4.4 IER
1. 1.4 Guidelines Notes
These were items from the generic IER that was originally proposed that seemed to fit better as notes for the overall 1.4 guideline.
Note 1: Success criteria 1.4.1, 1.4.3, and 1.4.6 address configuration at a global level, that is, it changes all of the text. Success criteria 1.4.2 and 1.4.5 are at an element type level, such as configuring just the heading text.
Note 2: All of the success criteria under guideline 1.4 allow users to override the text characteristics specified by authors, and override user agent defaults.
Note 3: The success criteria in guideline 1.4 can be met through user stylesheets. For platforms without user stylesheets, text configuration needs to be provide to users through the user agent's main user interface.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | 3 |
| Disagree with the proposal | 1 |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal | 2 |
(1 response didn't contain an answer to this question)
Details
| Responder | 1.4 Guidelines Notes | 1.4 Notes |
|---|---|---|
| Jeanne F Spellman | Agree with the proposal | |
| Kelly Ford | Suggest the following changes to the proposal | Note 3 provide needs to be provided but otherwise I agree. |
| Greg Lowney | Suggest the following changes to the proposal | Note 1 might be more appropriate in the Summary, as it's not adding any information, just calling it to the reader's attention. In Note 3 rather than "platforms without user stylesheets" I'd say "technologies or user agents without user stylesheets". |
| Jan Richards | Disagree with the proposal | None of the other guidelines have notes like this....so what to do? Perhaps a definition of "Text Customization, Set Text Characteristics" that we could then link from all instances of "set" in GL1.4? "Globally set" can then be a sub-defn. |
| Jim Allan | ||
| Simon Harper | Agree with the proposal | |
| Kimberly Patch | Agree with the proposal |
2. 1.4.1 & 1.4.2 Text Scale change to Text Size
This seems like an clarity improvement. Note that the importance of scaling headings with increased size has been lost in the new SCs. Jeanne and Kim added it into 1.4.1 (first bullet on Text Size) as part of their IER work. To view the earlier text, the 1.4.1 and 1.4.2 approved at the previous meeting.
1.4.1 Text Size, Color, Font (Globally):
The user can globally set all of the following characteristics of visually rendered text content: (Level A)
* Text size with preserved size distinctions (e.g. keeping headings proportional to main font)
* Text color and background color, choosing from all platform color options
* Font family, choosing from all platform fonts
1.4.2 Text Size, Color and Font (by Element):
The user can set all of the following characteristics of visually rendered text content for text element types including at least headings and input fields:(Level AA)
Text size
Text color and background color, choosing from all platform color options
Font family, choosing from all platform fonts
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | 4 |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal | 2 |
(1 response didn't contain an answer to this question)
Details
| Responder | 1.4.1 & 1.4.2 Text Scale change to Text Size | 1.4.1 & 1.4.2 Text Size |
|---|---|---|
| Jeanne F Spellman | Agree with the proposal | |
| Kelly Ford | Suggest the following changes to the proposal | * Text size with preserved size distinctions (e.g. keeping headings proportional to the main font) * Text color and background color, choosing from all platform color options * Font family, choosing from all platform font options |
| Greg Lowney | Suggest the following changes to the proposal | I find the concept of "font size" to be confusing in this guideline, as to when it means a specific size (e.g. 16 pt), when it means a factor applied to some base size (e.g. "large" and "larger" in CSS), and how these relate to a zoom or scaling factor applied to a viewport (e.g. a command to double the size of all on-screen rendering without affecting the size properties of the elements). For example, do we feel a global zoom feature should satisfy the first bullet of 1.4.1? If not, can that interpretation be justified by the current wording? Off-hand it seems like in 1.4.1 the user would specify some scaling factor, or a base size to which scaling factors apply, while in 1.4.2 it could be either a specific, absolute size for that element *or* a scaling factor. I’m concerned about the change to use the term "text size" in 1.4.1, which to me implies the user chooses a specific point size, and it would not make sense for the user to specify a single, absolute size for all text, as that prevents maintaining size distinctions of headings. Thus, I’d revert 1.4.1 to say "text scale" or "base text size". Minor, but I’m not entirely satisfied with the phrase "platform fonts", which sounds like fonts provided with the platform (e.g. those that come with the operating system), while in truth this is meant to mean all fonts available on the current system, including those which were installed by the user or other applications. (However, we don’t want to merely say "all available fonts" because that could be taken to mean the fonts made available by the user agent, which could be an arbitrarily small set, not to mention a tautology.) Perhaps it should be made explicit that characteristics set by 1.4.2 take precedence over those set by 1.4.1, as 1.4.1 does not say that it’s merely changing a default. Maybe something like "Note: characteristics set for individual text elements types (1.4.2) should override settings affecting all text content (1.4.1)."? |
| Jan Richards | Agree with the proposal | |
| Jim Allan | ||
| Simon Harper | Agree with the proposal | |
| Kimberly Patch | Agree with the proposal |
3. 1.4.1 IER
1.4.1 Text Size, Color, Font (Globally):
The user can globally set all of the following characteristics of visually rendered text content: (Level A)
* Text size with preserved size distinctions (e.g. keeping headings proportional to main font)
* Text color and background color, choosing from all platform color options
* Font family, choosing from all platform fonts
Intent of Success Criterion 1.4.1:
Some users with low vision, dyslexia, and related conditions and situations cannot read normally-formatted text. However, they can read text that has a format customized to their individual needs (e.g. larger letters, different font, more spacing). Users need to access a wide range of font sizes, styles, colors, and other attributes in order to find the combination that works best for their needs. In providing preferences, it is important to avoid making assumptions. For example, some users may increase font size to make text more legible, while other users may reduce the font size to decrease the need to scroll the content.
The relative size of text provides visual cues that help in understanding and navigating web content. Some content may be authored in a way that makes it difficult or impossible to understand when font distinctions are hidden, such as headlines that are in not in a larger font than body text. It's important that users who need to enlarge or reduce text size be able to preserve these visual cues.
Examples for Success Criterion 1.4.1:
* Lee has low vision from albinism and when the background is white, it is hard for her to read and hurts her eyes. She changes the colors in her operating system to white text on a black background. Some websites pick up the system colors and some do not, so she also changed the colors through her browser settings.
* Lee has low vision from albinism and has difficulty seeing small fonts. The browser on her mobile phone provides 3 font sizes: small, medium, and large. However, the large isn't big enough. The mobile phone settings provide an option to override the 3 font sizes with the operating system font range, so that Lee can select the specific font size she needs.
* Mike has a reading disability. A website uses a fancy script font for the headings that he cannot understand. He uses his browser's font settings to select plain fonts that he can read.
* Ben has low vision. In the mobile settings dialog box, he chooses a large text for font size. All applications on the mobile phone display text in large font.
* Sebeeya has low vision. She finds text easiest to read at 16 pt Palatino and chooses to have her browser display body text in the 16 pt Palatino font. She needs the headlines to scale proportionally (e.g. 24 pt) in order to preserve headline prominence.
Related Resources for Success Criterion 1.4.1:
Guideline 1.7 Enable Configuration of User Stylesheets
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | 3 |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal | 3 |
(1 response didn't contain an answer to this question)
Details
| Responder | 1.4.1 IER | 1.4.1 IER |
|---|---|---|
| Jeanne F Spellman | Agree with the proposal | |
| Kelly Ford | Suggest the following changes to the proposal | In the first example also changed should be als changes |
| Greg Lowney | Suggest the following changes to the proposal | In the first Intent paragraph, "and related conditions and situations" is a strange phrase, as the situations are actually related to low vision or dyslexia. In addition, the last clause in the paragraph is about users with physical disabilities affecting their ability to input, contrary to the lead-in the only discusses sensory disabilities affecting their ability to read. Thus it might be better to lead with a broader sentence. Here’s a suggested rewrite: "Users with some types of disabilities have difficulty reading pages that use normally-formatted text. Some users with low vision, dyslexia, and related conditions cannot read normally-formatted text. However, they can read text that has a format customized to their individual needs (e.g. larger letters, different font, more spacing). On the other hand, users with some cognitive disabilities, or who need to reduce the number of commands they enter to scroll through a document, may need to fit more information on the screen (e.g. smaller letters or spacing). Users need to access a wide range of font sizes, styles, colors, and other attributes in order to find the combination that works best for their needs. When providing preference settings and view options, it is important to avoid making assumptions that would limit the user’s formatting choices." The 2nd Intent paragraph is a bit misleading because it frames the issue as one of "relative size[s] of text", but in reality the relevant bullet item in the SC requires preserving distinction, but does not require the distinction be conveyed by size. In theory a user agent could render all the text as the same size, and use some other method (e.g. bolding, italics, or color) to denote various levels of headings. If the goal is to require *size* distinctions to to retained, the wording of the SC should be tightened up to convey that. In the 1st Example it says "Some websites pick up the system colors and some do not, so she also changed the colors through her browser settings." Is it usually possible for web pages to query the system colors? I suspect that usually the page would respond to the colors set through the browser, which might detect and pass on the system colors, in which case it doesn’t matter whether they’re changed through the system or the browser settings. The 1st and 2nd Examples both use Lee with albinism, but with very different needs. I think it would be less confusing to use separate people. Also, are there really mobile operating systems that can force the browser to provide a wider range of font sizes? The 2nd Lee Example and the Ben example seem redundant to each other, both being about using OS settings to make fonts larger. |
| Jan Richards | Suggest the following changes to the proposal | Some users with low vision, dyslexia, and related conditions and situations cannot read normally-formatted text -> Some users with low vision, dyslexia, and related conditions and situations cannot read text as the author has formatted it. Typo: that are in not in a that he cannot understand -> that he cannot decipher |
| Jim Allan | ||
| Simon Harper | Agree with the proposal | |
| Kimberly Patch | Agree with the proposal |
4. 1.4.2 IER
1.4.2 Text Size, Color and Font (by Element): The user can set all of the following characteristics of visually rendered text content for text element types including at least headings and input fields:(Level AA) * Text size * Text color and background color, choosing from all platform color options * Font family, choosing from all platform fonts
Intent of Success Criterion 1.4.2:
Some users with low vision, dyslexia, and related conditions and situations cannot read normally-formatted text. However, they can read text that has a format customized to their individual needs (e.g. larger letters, different font, more spacing). Users need to access a wide range of font sizes, styles, colors, and other attributes in order to find the combination that works best for their needs. In providing preferences, it is important to avoid making assumptions. For example, some users may increase font size to make text more legible, while other users may reduce the font size to decrease the need to scroll the content.
Users who need large amount of screen magnification need to control the appearance of types of elements. For instance, a magnification of 300% can make headlines too large for display. Users need to be able to set the characteristics of element types (e.g. heading 1, heading 2, table heading) to make the web content readable. Magnification users who find that text size distinction greatly increases scrolling and fatigue also need to be able to display important elements such as headings (including table headings) and input fields independently from global settings.
Examples for Success Criterion 1.4.2:
* Tomas has low vision and uses a screen magnifier. He chooses to have his browser display all text the same size, and sets that size as large as he can without making the letters too tall for his screen. Tomas chooses not to have headings be proportionately larger than normal text because that would make them taller than his screen and so unreadable. He uses a user stylesheet to make the different levels of headings a different color and surrounded with the number of equals signs (=) that matches of heading level.
* Adele is 84 and has macular degeneration and is experiencing fine motor problems. She loves using her mobile tablet to read her email and follow her grandchildren on social media. She has difficulty selecting text areas to enter forms. Her granddaughter helps her create a font size setting for input fields so that the text is larger and increases the area where she can tap, making it easier to enter text.
Related Resources for Success Criterion 1.4.2:
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | 4 |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal | 2 |
(1 response didn't contain an answer to this question)
Details
| Responder | 1.4.2 IER | 1.4.2 IER |
|---|---|---|
| Jeanne F Spellman | Agree with the proposal | |
| Kelly Ford | Agree with the proposal | |
| Greg Lowney | Suggest the following changes to the proposal | Re Intent paragraph 1, see my earlier comments about 1.4.1. In Intent paragraph 2, I found the phrase "be able to display important elements such as headings (including table headings) and input fields independently from global settings" is confusing; does it mean using global settings to determine whether something is displayed? How about "be able to control how important elements such as headings (including table headings) and input fields are displayed, overriding global settings"? Re the 2nd Intent paragraph, It’s not just large amounts of screen magnification, it’s also those who choose large or small fonts. The reason they need control over specific element types is that when the overall page is enlarged or shrunk to make the body text easy to read, it can make other certain element types too large or too small to read. That is, "Some users need to increase the size of most text on the page in order to make it easier to read or navigate. However, doing so can make certain element types, such as headings, too large to be easily read. Other users may need to decrease the size of most text on the page in order to avoid scrolling or to fit in a narrow field of vision, but doing so can make such element types, such as superscripts, too small for them to read easily. In both cases the user benefits from being able to customize how these element types are displayed, overriding settings for the overall document content. This can also benefit users who find the default text presentation fine, but have difficulty when elements are presented larger or smaller than that." |
| Jan Richards | Suggest the following changes to the proposal | Some users with low vision, dyslexia, and related conditions and situations cannot read normally-formatted text -> Some users with low vision, dyslexia, and related conditions and situations cannot read text as the author has formatted it. This (surrounded with the number of equals signs (=) that matches of heading level) isn't in the SC requirements. |
| Jim Allan | ||
| Simon Harper | Agree with the proposal | |
| Kimberly Patch | Agree with the proposal |
5. 1.4.3 IER
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | 4 |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | 1 |
| Suggest the following changes to the proposal | 1 |
(1 response didn't contain an answer to this question)
Details
| Responder | 1.4.3 IER | 1.4.3 IER |
|---|---|---|
| Jeanne F Spellman | Agree with the proposal | |
| Kelly Ford | Neutral, will accept consensus of the group | |
| Greg Lowney | Suggest the following changes to the proposal | In the 1st Intent paragraph, "as long as the result gives users multiple choices" would be more accurate as "as long as the result gives users enough choices covering a sufficient range of values". In the 4th Intent paragraph, I’d like to change the 2nd sentence to "Similarly, users of screen magnifiers find it cumbersome to read text whose leading edges don’t line up. These users need to be able to change fully justified or centered text to left or right justified, depending on the text language." I must admit that the introduction of bookmarklets, along with our frequent references to user stylesheets, scare me a little, as it suggests a browser can pass even though it doesn’t provide "out of the box" user controls for almost anything. This is why I earlier suggested that compliance claims differentiate between a user agent complying with an SC in its default configuration, complying with settings changes, complying with currently available add-ons, and merely being extensible enough to theoretically allow the creation of such add-ons. Which SC wouldn’t user style sheets and bookmarklets be enough to comply with? |
| Jan Richards | Agree with the proposal | Some users with low vision, dyslexia, and related conditions and situations cannot read normally-formatted text -> Some users with low vision, dyslexia, and related conditions and situations cannot read text as the author has formatted it. |
| Jim Allan | ||
| Simon Harper | Agree with the proposal | |
| Kimberly Patch | Agree with the proposal |
6. 1.4.4 IER
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | 7 |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal |
Details
| Responder | 1.4.4 IER | 1.4.4 IER |
|---|---|---|
| Jeanne F Spellman | Agree with the proposal | |
| Kelly Ford | Agree with the proposal | |
| Greg Lowney | Agree with the proposal | |
| Jan Richards | Agree with the proposal | |
| Jim Allan | Agree with the proposal | |
| Simon Harper | Agree with the proposal | |
| Kimberly Patch | Agree with the proposal |
More details on responses
- Jeanne F Spellman: last responded on 16, October 2013 at 21:37 (UTC)
- Kelly Ford: last responded on 17, October 2013 at 02:14 (UTC)
- Greg Lowney: last responded on 17, October 2013 at 06:03 (UTC)
- Jan Richards: last responded on 17, October 2013 at 14:00 (UTC)
- Jim Allan: last responded on 17, October 2013 at 16:47 (UTC)
- Simon Harper: last responded on 22, October 2013 at 16:17 (UTC)
- Kimberly Patch: last responded on 31, October 2013 at 17:41 (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