TAdER — Text Adaptability is Essential for Reading

Text Customization Requirements
[work in progress — updated 5 October 2013]

This page offers ideas on how text customization can be addressed in guidelines and standards.
For context, please read Text Customization for Readability.

Summary of customization and levels

Characteristics	Level
text size	overall: A at element level: AA
text color and background color	overall: A at element level: AA
font face	overall: A at element level: AA
zoom with reflow	A
linearization/reflow with flexible width	A
element-level customization	AA
printing customized text	AA
line spacing/leading/line-height	overall: AA
letter spacing	AA
word spacing	AA
justification/alignment	AA
line length	(covered by flexible width & reflow)
text style - underlining, italics, bold	overall: AA element level: AA
capitalization	AAA
hyphenation	AAA
margins	overall: AAA element level: AAA
indentation	@@
borders	overall: AAA element level: AAA
export text with semantic markup	AAA

---

Important notes on below:

• IMPORTANT: Some of the info in the tables below is old and I haven't updated it yet.
• Element-level: Users need to be able to distinguish between elements; for example, setting main paragraph text one way, each heading a different way, and navigation a different way. One approach would be to include some specific aspects of element-level customization at level AA, for example, for color, include element-level at AA and for borders include element-level at AA. Another approach would be to have a separate requirement for element-level customization that allows the users to chose 2 of a few options at level AA. Both ideas are drafted below...

Text Size success criteria

Also known as: font size.

Considerations:

• Settings: Ideally users can set any text size, ranging from 5 point to @@ point. [open?] However, in some "closed systems" such as eBook Readers, is this not feasible, and instead they can be allowed to chose from a limited number of point sizes? If so, which are acceptable?
• [open?] One option is setting a minimum size. Is that level AAA or other?
• [open?] If users can zoom effectively, is setting specific text size not required at Level A?

Proposed SC	Level	Related in guidelines	Support
[OPEN: maybe go with minimum instead?] Users can set the text size globally for all text. [need to say something like "offer a range of text sizes to the user that includes at least..." (from UAAG1:4.1)] For "closed systems": Users can select text size from at least the following options: 8, 10, 12, 14, 18, 24, 36, [what is acceptable minimum options?].	A	UAAG1: 4.1 Configure text scale (P1[Level A])	FF(6,17) - full (Tools>Options>Content) ReaderX - none
[OPEN: need this is have above?] Users can set a minimum text size globally for all text. [need to say something like "offer a range of text sizes to the user that includes at least..." (from UAAG1:4.1)]			O11 - full (from Tools>Preferences>Fonts>Advanced) FF(6,17) - full (Tools>Options>Content>Advanced) ReaderX - none
[NOT] Users can specify whether or not distinctions in the size of rendered text are preserved when that text is sized (e.g., headers continue to be larger than body text). [or users can change the text size of specific structural elements, including paragraphs and headings.]		UAAG1: included in 4.1 Configure text scale (P1[Level A])	OPEN: Do any UA's support this? (It's in UAAG 1.0.)
Users can set the text size of specific structural elements, including paragraphs and headings. [need to include more elements?]	AAA		ReaderX - none browsers - through user CSS.
Users can set the text size according to types, such as proportional and monospace.	AAA		FF(6,17) - full (Tools>Options>Content>Advanced) ReaderX - none?

Text and background color success criteria

Many people, especially people who are older, need high contrast to read text well. However, some people need low contrast, including people with some types of low vision and some types of cognitive disabilities, including dyslexia. For more info, see the Color section of Text Display Aspects that Users Need to Customize.

Considerations:

• Settings: Ideally, users can choose from a wide range of colors that are provided through the OS. [open?] However, in some "closed systems" such as eBook Readers, is this not feasible, and instead they can be allowed to chose from a limited number of color combinations? If so, which are acceptable, e.g., at least 2 high contrast and at least 2 low contrast? How specific do the requirements need to be, e.g., providing contrast ratio values for high & low contrast...

Note: WCAG 2.0 requires high contrast at Levels AA (SC 1.4.3) and AAA (Sc 1.4.6), , which decreases accessibility for some users. In WCAG 2.0, user customization of colors is at Level AAA. This is a problem.

(Note: Related to highlighting, e.g,. UAAG1:10.2, UAAG2: G1.3)

Proposed SC	Level	Related in guidelines	Support
Users can select text and background color combinations globally for all text from at least the following options: white on black, black on white, low contrast (below @:1) dark on light, low contrast (below @:1) light on dark, [more needed?]. (User selection will override author settings.)	A		ReaderX - partial. offers 4 high-contrast options: green, yellow, white text on black, and black on white; no low contrast options; "Use Windows Color scheme". (however, offers full customization as advanced feature, per below)
Users can set text color and background colors (separately, as opposed to pre-defined combinations) globally for all text from [a wide range of colors that includes at least... (something like this from UAAG1:4.3 )]. (User selection will override author settings.)	AA	UAAG1:4.3 Configure text colors (P1[Level A]) WCAG2:1.4.8 Visual Presentation, AAA ...Foreground and background colors can be selected by the user....	ReaderX - full. (Edit > Preferences > Accessibility). However, Edit > Accessibility >Setup Assistant... has only the high contrast options.
Users can set text color and background colors (separately, as opposed to pre-defined combinations) of specific structural elements, including paragraphs and headings [need to include more elements?] from [a wide range of colors that includes at least... (something like this from UAAG1:4.3 )]. (User selection will override author settings.)	AAA		browsers: using user CSS
[content guidelines] The default color contrast is at least 7:1.	AAA	WCAG2:1.4.3 Contrast (Minimum), AA... contrast ratio of at least 4.5:1... WCAG2:1.4.6 Contrast (Enhanced), AAA... contrast ratio of at least 7:1...	For content, not user agents

Font face success criteria

Also know as: typeface and font family.

Some fonts are extremely difficult to read and content could be totally inaccessible to people even with moderate low vision or reading disabilities. Some users will want to set the paragraph font different from the heading font to help differentiate them. Content providers sometimes use different types of font for different purposes, e.g., serif and san-serif. Some users would like to maintain such differentiation.

Considerations:

• Settings: Ideally, users can choose from a wide range of fonts provided by the OS. [open?] However, in some "closed systems" such as eBook Readers, is this not feasible, and instead they can be allowed to chose from a limited number of fonts? If so, what is acceptable, e.g., at least 2 simple serif fonts and at least 2 simple sans serif fonts? How define "simple?
• [@@ Content providers sometimes use different types of font for different purposes, e.g., serif and san-serif. Some users would like to maintain such differentiation.]

Implementing note to tool developers: When providing users a list of fonts to choose from, present the font name in the font itself — e.g., Times, Verdana, Courier — so users can tell what each font looks like.

Proposed SC	Level	Related in guidelines	Support
Users set change the font face globally for all text. [need to say something like "offer a range of font families to the user that includes at least..." (from UAAG1:4.2)] For "closed systems": Users can select font face from at least the following options: [simple] serif or [simple sans serif] font. [how define "simple" or other way to categorize? ask typographer]	A	WCAG2 - none UAAG1: 4.2 Configure font family (P1[Level A]) Allow global configuration of the font family of all visually rendered text content. ... ATAG2-21July2011: way too vaguely in A.3.6.	most browsers - full ff17 - full (Tools > Options > Content) ReaderX - none
Users can set the font face of specific structural elements, including paragraphs and headings. [need to include more elements?]	AAA		O11 - full (headings 1-6, form buttons, text field multi-line, textfield single-line, titles) (from Tools>Preferences>Fonts>Advanced) ReaderX - none
Users set change the font face according to font types, such as serif, sans-serif, monospace. [@@need to be more specific?]	AAA		O11 - full (normal, pre, serif, sans-serif, cursive, fantasy, monospace) (from Tools>Preferences>Fonts>Advanced) FF(6,17) - full (proportional, serif, sans-serif, monospace) (from Tools>Options>Content>Advanced) ReaderX - none

Zoom

Many user agents already provide some zoom functionality (incidentally, with an easier UI than increasing text size). However, most web browser zoom and PDF Reader zoom functionality does not "rewrap" text and instead creates horizontal scrolling, thus making the text inaccessible to some people, as explained in Scrolling to Read Text.

Considerations:

• Horizontal scrolling: Avoiding horizontal scrolling to read a line of text is a level A requirement. (It's OK for users to have to scroll horizontally to get to different sections of content.)
• [open?] What are the requirements of user agents and content? Real world accessibility will be better if the user agents zoom effectively regardless of how the quality of the content. Is that feasible? (Opera seems to do effective zooming regardless of content quality.)
• [open?] How handle the zoom percentage and small screens?
• [open?] WCAG 2 requires 200% yet some say that is not feasible for many websites [@@link].

(Some recent discussions that may be helpful: Browser zoom great for accessibility, including comments (August 2013), Easy Checks comments, Why Browser Zoom Testing Sucks for Accessibility, Text resizing: Why page zoom is not good enough - or is it? (updated 10 January 2012))

Proposed SC	Level	Related in guidelines	Support
Users can "zoom" to rescale all content up to 150% and down to 10% of the default size without requiring horizontal scrolling to read a line of text on a full-screen window, and without loss of information. [e.g., text going outside of containers or overlapping]	A	UAAG2:SC 1.8.6 The user can rescale content within graphical viewports as follows: * Zoom in: to 500% or more of the default size; and * Zoom out: to 10% or less of the default size, so the content fits within the height or width of the viewport. (Level A) UAAG2:SC 1.8.12 The user can request that when reflowable content in a graphical viewport is rescaled, it is reflowed so that one dimension of the content fits within the height or width of the viewport. (Level AA) Note: User agents are encouraged to allow users to override author instructions not to wrap content (e.g., nowrap). WCAG2:SC 1.4.4 ...text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA) WCAG2:SC 1.4.8 For the visual presentation of blocks of text, a mechanism is available ... Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window. (Level AAA)	Opera: @@full??? most browsers: partial requires horizontal scrolling ReaderX: partial "numeric zoom factor... between 0.0833 and 64 times actual size." requires horizontal scrolling
Users can "zoom" to rescale only text [not images, etc.] up to 150% and down to 10% without requiring horizontal scrolling to read a line of text on a full-screen window and without loss of information. [e.g., text going outside of containers or overlapping]	AA ? AAA

@@ Linearization/reflow success criteria

@@ ability to get an entire chunk of content (article, paper, story, etc.) in a single column. ability to change the width of the [viewing pane] and have text wrap to fit within it, to avoid horizontal scrolling.
(user need: it is impossible for some people to read multi-column text that goes off screen vertically, that is, for users to get from the bottom of one column to the top of the next and retain meaning from previous column) (note following one line across a horizontal scroll is difficult, getting to the next line is many times more difficult)

"Text in one continuous block, instead of in multiple columns (change it so that you/they do not have to go from the bottom of one column up to the top of another column to read text; e.g., changing text from 3 columns to 1 column; sometimes called reflow)"
Especially when text is enlarged, it can be extremely difficult for people to get from the bottom of one column to the top of the next column, and keep their reading flow.

See Scrolling to Read Text.

Proposed SC	Level	Related in guidelines	Support
Users can get related text (e.g., an article, a paper) in a single column.	A		Browsers - most support turning off style sheets so if content is authored well, then supported that way. ReaderX - insufficient. It's buggy overall. "Text that does not reflow includes forms, comments, digital signature fields, and page artifacts, such as page numbers, headers, and footers. Pages that contain both readable text and form or digital signature fields do not reflow." Cannot print reflowed. The find/search-in-page functionality does not work when reflowed.
@@ Users can get related text (e.g., an article, a paper) in a single column, can change the width of the [viewing pane] and the text wraps within the [viewing pane] (without requiring horizontal scrolling).	AA	WCAG2:1.4.8 Visual Presentation, AAA... Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.	Browsers - most support turning off style sheets so if content is authored well, then supported that way. ReaderX - insufficient. see details in above column

@@ Element-level Customization

@@ Users need to be able to distinguish between elements; for example, setting main paragraph text one way, each heading a different way, and navigation a different way. One approach would be to include some specific aspects of element-level customization at level AA, for example, for color, include element-level at AA and for borders include element-level at AA. Another approach would be to have a separate requirement for element-level customization that allows the users to chose 2 of a few options at level AA. Here's the second approach.

See Element-Level Customization.

space before & after

Proposed SC	Level	Related in guidelines	Support
	AA

@@ Printing Customized Text

"...print text after you/they have customized it to make it easier to read"
It is difficult for some people to read text on the computer; they need to be able to print electronic text on paper in order to read it. See Printing Customized Text.

Proposed SC	Level	Related in guidelines	Support
	AA

Line spacing/leading/line-height success criteria

That is: the space between lines in a paragraph.

Considerations:

• Settings: Ideally users can set leading ranging from 0.7 to 3.0 at 0.10 increments. [open?] However, in some "closed systems" such as eBook Readers, is this not feasible, and instead they can be allowed to chose from a limited number of leading options? If so, which are acceptable?

Proposed SC	Level	Related in guidelines	Support
Users can set line spacing at 1.0, 1.5, or 2.0 globally. (as opposed to per element)	AA	WCAG2:1.4.8 Visual Presentation, AAA... Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.	ReaderX - none browsers: full with user style sheets
Users can set line spacing between 0.7 and 3.0 at increments of 0.10 globally. (as opposed to per element)	AAA		ReaderX - none browsers: full with user style sheets
@@ line spacing element level	AAA		ReaderX - none browsers: full with user style sheets
@@ Users can set line spacing above and below specific structural elements, including paragraphs and headings [need to include more elements?], between 0.7 and 3.0 at increments of [tenths of percent (0.1)].	AAA		ReaderX - none browsers: full with user style sheets

Other level AA success criteria

@@ space between elements

...@@ covered in margins (but that's AAA), or at element-level ???
"Space between elements (e.g., space between paragraphs, or space above headings)"
why: Having additional space between elements helps most people group information. For example, having more space above a heading, and less space below it help associate the heading with the text below.

justification / alignment

(left, right, full/both, centered), particularly undoing full justification.
why: Sometimes full justification makes reading more difficult because extra space between words causes "rivers of white", or less space between words makes it difficult to distinguish separate words. Some people find it easier to track from the end of one line to the next with full justification, and others prefer left justification (for left-to-right languages).

line length

the number of characters per line - how long or short the lines of text are.
why: It is more difficult to read very long lines of text.

text style

underlining, italics, bold - usually removing the text styles.
why: For some people, it is difficult to read text that is underlines or italicized. For some, bold text is easier to read.

word spacing

the space between words

letter spacing

the space between letters/characters in words

Level AAA success criteria

capitalization

all capital letters, small capital letters, sentence style.
why: Text in all capital letters is more difficult to read for most people.

margins

blank space around blocks of text.
why: Having wide margins around blocks of text helps focus on the text and not get distracted by surround text, images, etc.

borders around blocks of text

including border line color, width, style.
why: Some people prefer to use borders to indicate headings, rather than have them much larger than the main text.

indentation

e.g., space in front of list items, the first line of a paragraph.
@@ overlap with margins at element level ?

hyphenation

turning it on or off (word breaks; when a long word is at the end of a line, either separating the word with a hyphen, or putting the whole word on the next line.
why: For some people it is especially difficult to understand words that are hyphenated.

export (or copy & paste) text along with its semantic markup

...
why: so people can use different user agents with better text customization functionality

(Not included)

@@ The ability to "zoom" with UNproportional text increase — [UAAG draft wording "Preserving Size Distinctions: 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)"] "...choose whether or not all text increases proportionally; for example, headings remain bigger than main paragraph text"

@@template

@@

Proposed SC	Level	Related in guidelines	Support

 

---

Acknowledgments

Thank you for contributing your perspectives on this material:

• Wayne Dick
• Michael Cooper

[in-progress draft] Misc notes

• Of great concern is the difficulty in changing settings - even finding the options. In most browsers some of these are several steps through menus and dialog boxes. (In ReaderX, the color options are on 2 of 5 required dialog boxes.)
• Opera 11.6 also allows font settings for Browser menus, toolbars, dialogs, panels, and tooltips - from Preferences > Fonts > Advanced.

Note: Element level customization

Users need to be able to distinguish between element types, e.g., heading levels. With large text, size is often a poor discriminator. Aspects useful for distinguishing head levels are: color, font face, style (e.g., bold), underlining (box model properties), and space above and below.

Also useful is being able to customize by "roles" —e.g., titles, sidebar heading, sidebar text, footnotes— such as provided by HTML5 role attribute.

WayneD perspective: Not need element level: leading, letter spacing, word spacing, font size.

Note: Difference between simple legibility and readability

Background: Readability beyond legibility

OPEN: Does this mean we can have more lenient requirements for small bits of text, e.g., form field labels? If so, how to we define the larger "blocks of text" or whatever-it's-called for which there are more requirements? WCAG 2 defines "blocks of text" as "more than one sentence of text". The page is for blocks of text.
OPEN: What is required for small bits of text? Yes: font face, text size, color. No: line spacing, linearization. ?

Note: Range of technologies and devices

@@ HTML, word processing, PDF, eBooks, ...

@@ Desktop computers, laptops/notebooks/tablets, mobile phones, eReaders, ...
[For now, this page is primarily for web in robust OS. Ideas for "closed systems" such as basic eBook readers are include in some places.]

@@ different requirements -- e.g., closed system can provide limited font choices, whereas browser etc should pull from all OS fonts...

misc

no horizontal scrolling - readability, word, mobile browsers?

@@O/S ->platform

Text Customization Requirements by Shawn Lawton Henry is licensed under a Creative Commons Attribution 3.0 Unported License.