WCAG 1.4.8 item 5 200%

[allanj-uaag]

Current: 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.

related to User Need - 3.3.1 Text Size, 3.2.3 Line Length, perhaps 3.2.4 Hyphenation, 3.2.2 Reflow to Single Column, 3.2.1 Rewrap for One Direction Scrolling

[allanj-uaag]

increase level to AA and reword edits enclosed in @@

5. Proposed rewording: Text can be resized without assistive technology up to @@1100% @@ in a way that does not require @@bi-directional@@ scrolling to read a line of text on a full-screen window.

references:

• Effects of Word Width and Word Length on Optimal Character Size for Reading of Horizontally Scrolling Japanese Words http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4754429/
• Psychophysics of reading--I. Normal vision. https://www.psych.nyu.edu/pelli/pubs/legge1985reading1reprint.pdf
• Psychophysics of reading--II. Low vision. https://www.psych.nyu.edu/pelli/pubs/legge1985reading2reprint.pdf

https://www.w3.org/2016/06/16-lvtf-minutes.html#item03

[alastc]

Sorry to jump into an LVTF conversation without all the context, but that does not seem realistic for a couple of reasons.

Firstly it simply isn't supported by browsers at the moment. Chrome tops out at 500%, Firefox & Safari are less than that from a quick test.

Secondly, I'm not sure that's possible in a website context. At 500% on a 1024px wide desktop screen I'm getting 2 or 3 words per line. At over 800% you'd have to scroll if there's a long word! At that stage you might be better off with one of those one-word-at-a-time speed reading approaches? (Kidding).

The research linked to talks about sizing in terms of degrees. I didn't understand a lot of the terminology in there, could you translate what you think 1100% is in terms of physical size or pixel size? (CSS pixels are defined as 0.0213 degrees https://www.w3.org/TR/CSS21/syndata.html#img-pixel1). Does that mean type that is 3 degrees (tall?) is 140 pixels? (3 / 0.0213)

One of the explanations I heard around the time of WCAG2 (and made sense to me) was that if you need 'extreme' zoom levels then zooming in on web-content is not enough, you would not be able to read anything else on your system (like menus).

What is the cross-over point? I.e. if someone needs more than (say) 200% at what point do they need assistive technology to use their computer/device at all?

There are good arguments to increase the level to 300% or 400% based on: because it's easier to do now. However, I don't understand the argument for more than 400% as web content is one of many things you can't read.

[patrickhlauke]

One question I'd have here is also: are we suggesting 1100% without any AT? if a user needs that level of magnification, would they not badly struggle with everything else (like their actual browser/UA)?

[lauracarlson]

Related email from Allan Smith: 1100% may be physically impossible and still not achieve the results on smaller monitors

WCAG WG Wiki Page: Possible wording from Jason/David for LVTF re: zoom without horizontal scroll

[WayneEDick]

An Image of 1100% Text Enlargement

• font-size is 176px = 11x16px
• line-height is 1.5
• font-family is verdana
• screen size is 22 in.
• width is about 19in.
• height about 11 in.
• resolution is 1920x1080 about 100px per inch

Each letter is about 1.76 inches. That seems ridiculously large, but look at the picture. The text is readable and there is a large enough chunk to make sense. Note that 176px is 1100% of 16px. 1100% looks practical from the reader's point of view.

One thing most people do not appreciate is that reading word wrapped text is much more efficient than reading magnified text. Without word wrapping the line truncation produced by dumb magnification, a lot more information can be displayed even with 1100% enlargement. This is very usable.

.

[alastc]

That's good for you, but the same 1100% guideline has to be applicable to people who set their resolution (no matter screen size) to 800x600, and possibly people on mobile devices with a screen width of 320px.

[scottmssb]

You are never going to get agreement on what the minimum text size should be because everyone is going to have different needs. The most important part of this SC is that text can be resized without requiring horizontal scrolling.

As a low vision person myself and having trained many people with low vision I've observed that the level of magnification needed varies a lot depending on the person and even the situation. I myself can vary between 2x and 6x depending on the situation.

Requiring such a high level of magnification without the use of AT is problematic for a number of reasons:

• User agents and Operating Systems are limited in their support in text size changes with most settings limited to 200% without making use of hidden or unsupported configuration settings.
• Adjusting the text size without also adjusting other aspects of the UI will create layout and presentation issues that the UI may not be able to adjust for and this problem only gets worse as the text size increases. Windows, while it has gotten better, is particularly bad about this. Anyone who has tried to use the large or extra large themes included with Windows will notice very quickly that many if not most application exhibit display issues when the text is larger than normal. Most web browsers will only enlarge text up to 200%-300% using the standard UI and most browsers now default to zooming the entire UI not just the text which will likely cause horizontal scrolling. The web in theory can handle this much better but in practice most sites these days have layouts that restrict their layouts. Responsive design is helping reverse this somewhat but in most cases it is not responsive enough to cover all possible situations.

One aspect of the current SC that has me concerned is the full screen requirement. My vision for example is somewhat restricted so when reviewing the screen even without magnification I can not see the entire screen at once and if I enlarged the text to the point I could read from a distance so I could see the entire screen I would not be able to see the non-text portions of the UI very well if at all. Just the other day I was playing a video game where the game put button sequences on the edges of the screen. Being only able to see about 1/4 of the screen at a time I spent a good 20 minutes trying to figure out why I could not get further in the game because the game was showing a button sequence on the left edge of the screen (outside my field of vision) so until I backed up enough to observe the entire screen and could see the icons pop up on the various edges I didn't know what to do. Some users (like me) would prefer to have a browser window set to a manageable size and still be able to read without horizontal scrolling.

We need to be less restrictive in our requirements here. At the end of the day we are trying to say the text should be readable when the font size is increased as this is what typically happens when text is magnified without the use of AT. This ultimately means the text and associated layout needs to linearize properly without the need for horizontal scrolling.

I'd suggest something like this: 5.Text can be resized without assistive technology @@at least@@ 200 percent in a way that does not require the user to scroll horizontally to read a line of text

This is a small change but it says that 200% is now the minimum rather than the target maximum. It also takes away the full screen expectation as this could be a way for authors to make width assumptions that could cause horizontal scrolling or other UI problems. If the UI can linearize properly we should have very few cases where horizontal scrolling is the only option.

[WayneEDick]

Text Enlargement Is Poorly Understood by the A11y Community

Most accessibility people's experience with text enlargement is geometric zoom (GZ). Even with sophisticated curve smoothing this is the most primitive concept of enlargement. It is a geometric operation that is unrelated to the semantics of written language. GZ is implemented in operating system’s and browser’s zoom. Screen magnification software implements GZ as well as possible.

The model for enlarging text that best fits user needs for partial sight is semantic text resize (STR). The word processor is the most familiar example. You find a semantic object like normal running text, and you set its size. Everything magically reflows to reflect your choice. We have at least two implementations that support this model: word processors and markup language.

GZ creates two profound negative consequences: loss of the continuity of text caused by line truncation, and navigation difficulty caused by bi-directional scrolling (horizontal and vertical). STR solves both problems, and this enables much larger resize factors without disruption of reading. (See the comparison below and (Legge, [1])

In my example on enlargement to 1100% [3], I illustrate that word wrapped content where the font size has been increased by 1100%, produces very readable text on a 22-inch screen. Gordon Legge, author of The Psychophysics of Reading for Normal and Low Vision, demonstrated a similar example for 1000% enlargement on a 9.7-inch iPad 3 [1].

At some point, even enlargement with reflowed text fails. You hit a wall caused by the width of the display medium. At that point you must decide on a tradeoff between a desired text size and the minimum number of characters per line that make reading sense. Semantic text resize is not really a scaling factor problem. It is a problem of word fit.

This was the problem Gordon Legge and I were trying to solve when we came up with the 1100% scale. We were trying to fit 10 to 15 characters per line on a screen, and compute a reasonable scaling maximum to fit that character count. Legge managed to fit 15, 9 point characters on the iPod 3 landscape screen with a 1000% STR, [1]. Reconstructing my work for 15 characters on a 22-inch screen I developed my 1100% STR example for Issue 5 in the LVTF SC Github [3].

Attempting to come up with a zoom maximum was probably an error. I was trying to force a geometric limit for an operation that was semantic. What makes semantic sense is a maximum character count per line. That should be somewhere between 10 and 15 characters per line.

Since, characters per line depends on the font-family, a more practical measure would probably be EM units per line. Since the EM count and character count differ I was hesitant to propose an EM or character count to the A11y community because of the complexity of this difficult argument. That seems to have caused more confusion than it was worth. My example was based on an EM count, Legge's was based on a character count for a given font family. Since EM count is greater than character count we should probably define our SC in terms of typographic EM units. The SC should be stated as something like: Documents should support a maximum line length of 10 to 13 EM units per line. For screens of size 22 inch this will support 1100% for most fonts. For small screens the enlargement will be smaller, but the text layout will be readable. A maximum EM count will give the maximum semantic text resize possible for a given medium.

I close with a comparison of STR to GZ. The take away is that you have more readable information with 1200% Semantic Text Resize than you do with 500% Geometric zoom.

Example 1

Comparing STR to GZ at 1200% Enlargement on a 22-inch monitor.

Below are screen shots of text enlargement by 1200% using text enlargement and zoom respectively. Screen size is 22-inch.

Starting at the top line the text enlargement with word wrap has a sequence of ten words in reading order. The entire sequence makes logical sense. The top line of the zoomed screen shot has only three complete words in reading order. The rest of the screen is filled with disconnected word sequences. One can easily understand how a person would think 1200% enlargement was excessive in an environment only providing zoom. Three words per screen is not very useful. In our example we have 14 characters of signal, and more than 50 characters of noise when we use 1200% zoom, a terrible signal to noise ratio. The text enlargement has 57 characters, 10 complete words in logical sequence, with no noise. Ironically, the zoomed page has more characters, but the word wrapped page has more meaning.

The images are taken from my article [2], "Because I am not blind", based on a quote by Sam Genenski inventor of the CCTV for reading.

 

Figure 1: Fully word wrapped 16px tahoma text enlarged 1200%

Figure 2: The same is text enlarged with zoom. "Few people have", is the only meaningful sequence starting from the top. This is of marginal use, and greater enlargement will only harm.

Example 2:

Comparing STR and GZ at 500%

In this example we see why GZ tops out at 500% enlargement. Any larger and the navigation problem combined with too little visible useful content makes larger GZ impractical. STR is more usable at 1200% than GZ is at 500%


Figure 3: This figures shows a meaningful sequence of 69 words, numbers and abbreviations. Every line follows semantically from its predecessor


Figure 4: This image has 9 lines of text. They are semantically disjoint. If you start at the top, only the first line is useful without scrolling horizontally to fill in the gaps.

[1] Gordon Legge, Comments to the U. S. Access Board, 2015

[2]"Because I am not blind", Wayne Dick, 2015

[3] Wayne Dick, An Image of 1100% Text Enlargement, Issue #5 WCAG 1.4.8 item 5 200%, LVTF SC Git Repository

[WayneEDick]

I think we are actually talking about the same thing, but you are not taking the LVTF transformations as a whole into account. When we include, linearization and element level customization, 1100% enlargement if you want it is accessible at the browser level.

I doubt the LVTF is proposing full screen only. What we do want is display of the block elements in linear format. One should be able to view that as wide or narrow as needed. For text we say that the user can choose the line length. LVTF has settled on that. Linearized display enables unlimited enlargement with reflow. Without content that can display in a linear format, one cannot write AT that resizes text with reflow as large as is needed.

I did not address tables or images because we were talking about text resizing. However, tables could be handled like this. We require that every table cell containing text is no wider than the width of text columns determined by the user. You may need to scroll horizontally to go from cell to cell in the same row, but no cell will be wider than a line of text you can read. Table text will always word wrap within cells.

Every standard browser could support the user’s required text resize within this context. It would require appropriate extensions that support style profiles for users. You don’t use zoom. You prescribe the text size element by element. In this environment users could enlarge as far as they desired.

There should be no size limit. The user should just be able to customize at the element level to obtain the best font size that fits on the screen or viewport of the user's choice. For practical reasons the line length will rarely get smaller than 15 characters per line. You will also see few pages with less than 3 lines per page. So the dimensions of the viewport will limit the practical font size. Again, users can choose the tradeoff between font size and viewport information density.

A user who requires a narrower viewport will pay for that choice in font size. Each person will find the best balance. But, for many users 1100% will be most practical when supported with full word wrap and hyphenation. Remember low vision includes the severe range (20/200 to 20/400), and many of those people read visually and need extreme enlargement. Right now AT doesn't provide that as a practical option because the current price of extremely large font size is horizontal scrolling. However, HTML with CSS and/or JavaScript can do it now for content that linearizes. Once content is constructed to support linearized display of block items, such extensions will be possible.

The contribution of responsive web design is to prove llinearization is possible on complex active sites. The fact that current authors erect barriers to this access is a problem of authorship. Content can do it. Linearization is possible with full functionality. With that quality of content, font size that fits the user need is more possible inside the user agent than it is with the current AT.

[alastc]

The question at hand was about an SC for a minimum level of text re-size, it isn’t really for WCAG to define maximums (unless we take on the user-agent side as well).

I appreciate the improvement that re-flow has (which I think is the same as what you mean by STR), and I certainly think we should increase the minimum “resizability” without horizontal scrolling. (In WCAG 2.0 there is nothing about horizontal scrolling at level AA.)

However, there are practical limits we have to account for when defining a minimum. We aren’t just talking about text-based documents, we have to account for things like Gmail and Angry Birds which would not linearize that easily.

If we define a very large minimum then it will be ignored, or people will use the caveat about needing their navigation and general interface to be spatially laid out (like tables and maps).

On desktop there is a natural size increase that is easy to do with a responsive web design (RWD), I think we should set that as the minimum. (A site doesn't have to use RWD, but that is a relatively easy method.)

What I mean by natural size is that typically you design for a mobile size (minimum of 300px ish) that expands to desktop size (over 1000px).

Therefore a user can zoom in by 300% easily (perhaps 400%) to get to the mobile view on desktop and it is still within the design parameters of the website. I.e. it works without horizontal scrolling or text-overlapping.

The trickier question is what we define as a minimum for small screen devices. They do not have the same type of layout mechanism, and automatically apply horizontal scrolling on zoom. I think we might need an exception until the browsers change as there is nothing a website author can do about it.

I agree with version 4 outlined here as a good approach to this (perhaps at 400%), I think anything more and it goes beyond the practicality of making websites and would be ignored/rejected: https://www.w3.org/WAI/GL/wiki/Possible_wording_from_Jason/David_for_LVTF_re:_zoom_without_horizontal_scroll

[WayneEDick]

We are only talking about text resize. Each resize like 1.4.4 and 1.4.8 only refers to text resize only. I got all specific with STR to make it clear we are only talking about text. The semantics of resizing text requires reflow and hyphenation. Maybe I just should have R&R (resize and reflow).

The reason I called resize with reflow with hyphenation semantic text enlargement is because text has semantic properties that a resize algorithm must attend to if meaningful resize is possible.

Geometric zoom for images might make an overall assessment impossible, but images and video are geometric objects and geometric zooming is appropriate. Applied to text, geometric zoom violates the semantics of language.

Extreme zoom for text is possible; it will work well, but it can't work if the semantics of written language are ignored.

[shawna-slh]

Discussion in teleconferences:

• https://www.w3.org/2016/07/14-lvtf-minutes.html#item01

[alastc]

From the discussion it looks like a staged approach is likely? (Something in 2.1, something stronger in silver...).

But no-one took the idea about the 'natural size' increase?

On desktop there is a natural size increase that is easy to do with a responsive web design (RWD), I think we should set that as the minimum. (A site doesn't have to use RWD, but that is a relatively easy method.)

What I mean by natural size is that typically you design for a mobile size (minimum of 300px ish) that expands to desktop size (over 1000px).

Therefore a user can zoom in by 300% easily (perhaps 400%) to get to the mobile view on desktop and it is still within the design parameters of the website. I.e. it works without horizontal scrolling or text-overlapping.

Wayne is focused on reading blocks of text, but it also needs to apply to layout & functionality, and most sites will break above 400%.