This repository has been archived by the owner. It is now read-only.

Adapting Text (original issues 79, 78, & 74) #124

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@lauracarlson
Copy link
Contributor

lauracarlson commented Feb 12, 2017

Latest text and info:

SC Shortname

Adapting text

Note: This SC merges 79 Font Family, 78 Spacing, and 74 Text Color as they are very similar in aim (ability to override and adapt text).

SC Text

No loss of content or functionality on a webpage is caused by overriding:

  1. font family to Verdana, or
  2. foreground and background to white on black, or
  3. line height of all text to 1.5, letter spacing to 0.12em, and word spacing to 0.16em.

Suggested Priority Level

Level AA

Related Glossary additions or changes

None

What Principle and Guideline the SC falls within.

Principle 1, Guideline 1.4

Description

The intent of this Success Criterion is to help ensure that people with low vision who override font family, text colors, and spacing can perceive content. People with low vision often must override author settings via user stylesheet, bookmarklet, extension or application such as VIP-PDF Reader.

This SC sets metrics for a normative testable baseline. Testable values (Verdana/white&black/EMs) are intended to provide a standard baseline, any particular user is likely to choose different values (especially font & color). The point is that this baseline is used to test the layout and functionality, and if it works then it is robust enough for certain user-adaptations (up to a point).

Verdana was chosen as a testing measure because it is a web safe font that is designed with a large x-height (the lowercase letters are bigger compared to the uppercase letters) and extra space between characters so they don't touch. If Verdana works most other fonts should work too.

White on black was chosen because if that combination works, 99% of all other combinations should be able to be overridden.

Line-height, letter-spacing, and word-spacing metrics were chosen as measures based on Research. McLeish ran from .04 to .25 em tests (Wayne E. Dick PhD analyzed the McLeish study and translated from points). McLeish found an increasing curve in reading speed of actual materials up to .25, but it really started to flatten at .20. Previous studies that reported no improvement started at .5em. Right at the flat point. Hence Wayne recommends letter spacing be 0.12em, and word spacing be 0.16em for this SC.

The plan is to start testing sites with these metrics on the various user-agent tools, primarily bookmarklets created specifically for this. See where problems surface. Adjust measures if needed. And then provide techniques.

Benefits

Font Family

Some fonts/typefaces are more readable than others. For example, some people cannot read fonts with sub-pixel rendering...

User Need: Users can change the font face (also called font family or typeface) of all text, choosing from a wide range of fonts including sans serif and serif fonts..

Source: Accessibility Requirements for People with Low Vision, Section 3.3.2

Text Color

...some people need low brightness, especially for backgrounds. Some people, who need low brightness for backgrounds, also need low brightness overall, and thus need low-brightness text.

Other people need high contrast between text and background, including many older people who lose contrast sensitivity from ageing. Some read better with dark text on a light background.

For some people, common color combinations or colors from a limited color palette work fine. For example, black text on a white background, or the inverse, with white text on a black background. Other people need to select more-specific background and text colors. For example, people, who require low brightness overall, need to select the specific background and text colors that provide sufficient contrast for them, yet not too-high brightness. Readable and optimal color combinations differ vastly among individuals, and can even vary from one individual to another, depending upon conditions such as fatigue and lighting.

Figure 8: Web page with author-defined colors with low contrast - light background, gray text, light green headings:

screen capture

Figure 9: Web page with user style with medium contrast - brown background, tan text, headings of different dull colors:

screen capture

Figure 10: Web page with user style with high contrast - black background, white text, headings of different bright colors

screen capture

User Need - Contrast: Users can set the background color and the text color from the full color spectrum.

Source: Accessibility Requirements for People with Low Vision, Section 3.1.2 Text Contrast

Spacing

Spacing such as space between lines and space between words impacts readability.

The space between lines in a block of text is also called leading. Some people need more space between lines to be able to read text. Line spacing also helps with tracking.

User Need: Line Spacing: Users can change the line spacing (leading) for blocks of text.

Source: Accessibility Requirements for People with Low Vision, Section 3.4.1

Some people need more space between letters to read text.

User Need: Letter Spacing: Users can change the letter spacing (space between letters/characters) of blocks of text.

Source: Accessibility Requirements for People with Low Vision, Section 3.4.2

Some people need more space between words to read text.

User Need: Word Spacing: Users can change the word spacing (space between words) of blocks of text.

Source: Accessibility Requirements for People with Low Vision, Section 3.4.3

Testability

Using a bookmarklet, user stylesheet, or VIP-PDF Reader change:

  1. font family to Verdana
  2. foreground and background to white on black
  3. line height of all text to 1.5, letter spacing to 0.12em, and word spacing to 0.16em.

Expected Results

  • No loss of content or functionality.

Techniques

Existing Related Techniques

New Techniques

  • Allowing for override of font family (future technique)
  • Allowing for override of text color (future technique)
  • Allowing for override of spacing (future technique)

Related Information

Research

Email

Minutes

GitHub

Surveys

Wiki Pages

@lauracarlson lauracarlson changed the title Initial add of Adapting Text Issue 78 Adapting Text Issue 78 Feb 12, 2017

@lauracarlson lauracarlson changed the title Adapting Text Issue 78 Adapting Text Issue. (original isssue 78) Feb 12, 2017

@lauracarlson lauracarlson changed the title Adapting Text Issue. (original isssue 78) Adapting Text (original isssue 78) Feb 12, 2017

@lauracarlson lauracarlson changed the title Adapting Text (original isssue 78) Adapting Text (original issues 79, 78, & 74) Feb 12, 2017

@lauracarlson lauracarlson referenced this pull request Feb 12, 2017

Closed

Adapting text #78

@lauracarlson lauracarlson reopened this Feb 14, 2017

@lauracarlson

This comment has been minimized.

Copy link
Contributor

lauracarlson commented Feb 14, 2017

Hi @KimberleeD ,

Thank you for your comment on the February 14, 2017 survey. You indicated, "This proposed SC needs more discussion" and asked:

Does this include all text? Even text on a button or other control?

Yes. People with low vision need to be able to read text. The plan is to start testing sites with these metrics on the various user-agent tools, primarily bookmarklets created specifically for this. See where problems surface. Adjust measures if needed. And then provide techniques.

@lauracarlson

This comment has been minimized.

Copy link
Contributor

lauracarlson commented Feb 15, 2017

Hi @DavidMacDonald,

Thank you for your comment on the February 14, 2017 survey. You indicated "Accept this proposed SC into the Editor's Draft" and wrote:

There may be some concern from some stakeholders regarding the requirement for everything to work when the user takes the site into his own hands and runs a script over it.

You may be right, David. With most sites implementing responsive design it may hopefully be less of an issue.

In any event, it may depend on the measures we end up with. As I said to Kim the plan is to start testing sites with these metrics on the various user-agent tools, primarily bookmarklets created specifically for this. See where problems surface. Adjust measures if needed. And then provide techniques.

@lauracarlson

This comment has been minimized.

Copy link
Contributor

lauracarlson commented Feb 15, 2017

Hi @jasonjgw ,

Thank you for your comment on the February 14, 2017 survey, Jason. You indicated "Accept this proposed SC into the Editor's Draft" and wrote:

This proposal is clear and testable, but unfortunately it states a testing technique rather than asserting the underlying requirement, which, as I understand it, is to allow fonts, spacing and color to be set arbitrarily by the user. While I don't object to its inclusion in the draft, I think it should be rewritten in terms of its underlying goal.

This has been discussed at length and the SC text has been through many iterations.

It still is a conundrum.

Currently the underlying requirement is unfortunately not to allow overriding font, spacing and color to any value desired by the user. Instead it is to allow overriding to specific values due to the SC criteria of testability.

@alastc has explained the underlying rationale of the hard-coded metrics approach:

...if it can't be tested true/false from the SC text, it won't meet the SC criteria. You can flesh things out in the understanding doc, but the SC needs to be a true/false statement...

If my team tests a page with Verdana and black & white, and another team tests the same page with "Latin Wide" (or some other very differently sized font) and purple and green, we will get different results.

Not due to subjectivity, but objectively different results.

Given where these SCs are used (including for lawsuits), I think Gregg is right to say we need normative testability.

If there were some way to state the requirement without a specific font/color/size value and still have it be testable, that would be great. But it has to be a content requirement, not a user-requirement, and that means specific values.

@WayneEDick has summed up the concern of many in the low vision community with naming specifying hard values:

If you wonder why the people with low vision are so skeptical of narrow SCs when what we need is flexibility...We know well that normative language is what becomes law. Putting single point conformance in an SC is dangerous. It is the FPWD so let's get it there. If single point normative language is all we can get in 2.1, so be it.

Jason, can you suggest SC text that would:

  1. state the requirements without specific font/color/size values AND,
  2. still be objectively and reliably testable?

We would all love to change it, if it is possible.

Thank you very much,
Laura

@steverep

This comment has been minimized.

Copy link
Member

steverep commented Feb 17, 2017

To make this easier for draft readers to swallow, consider adding a normative note that the resulting transformed webpage would not also be required to conform. The key is to not lose content or break navigation, forms, etc. Mostly this comes into play when messing with color, and this could be extra important to state given all the new criteria being proposed. Example might be an input field that is highlighted dark red on validation error no longer has the author's desired contrast. It's been a while since I've used style extensions regularly to alter content, but I remember often paying a price on such things for the benefit of being able to read the bulk of content.

@awkawk

This comment has been minimized.

Copy link
Member

awkawk commented Feb 18, 2017

merged to FPWD_review

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.