Why Browser Zoom Sucks for Low Vision Users
37
-
Upload
denis-boudreau -
Category
Technology
-
view
1.950 -
download
2
description
The way in which the Web Content Accessibility Guidelines (WCAG) 2.0 address text enlargement at conformance Level AA is rather ambiguous. Success Criterion 1.4.4 entitled “Resize Text”, states that “text can be resized without assistive technology up to 200 percent without loss of content or functionality.” The ambiguity surfaces within browsers like Safari or Firefox, which enable users to choose between zooming the entire page and resizing only the text within the page. These features, clearly intended for users who need larger print, often reveal serious structural defects in web pages that prevent reading functionality. Words are truncated, lines with fixed height overlap and poorly styled column formats cause one column to overwrite the column next to it. With page zoom, none of these problems occur: this is because everything, including bounding boxes, line height and column size are all expanding at the same rate. The problem however, is that the page no longer fits on the screen. Word wrapping fails and one has to stretch the word functional to claim that page enlarged in this manner remain functional. So really, can we consider a page to be conforming to Success Criterion 1.4.4 if it looks good when zoomed, but breaks when the text contained in it is simply resized? In other words, if page zoom is considered a viable approach to testing SC 1.4.4, and considering that pages never break when they are simply zoomed in, should we still consider this Success Criterion as relevant today?
Transcript of Why Browser Zoom Sucks for Low Vision Users
Denis Boudreau Deque Systems, Inc.
[email protected] @dboudreau
SUCKS
Wayne Dick CSU Long Beach [email protected]
An <a11yRant/> production.
It all started with this.
Or rather, this… (200%)
Actually, maybe even this… (300%)
But more specifically, THIS.
Thomas Henry Huxley (1869)
Leading to heated internal debates
Why BOTHER with SC 1.4.4 if it NEVER FAILS!
Web Developers vs. End Users
Web Developers vs. End Users
What Web Developers Want Easy Solutions Reliable Testing Measurable Results
Browser Zoom
Web Developers vs. End Users
What Web Developers Want Easy Solutions Reliable Testing Measurable Results
Browser Zoom
VS. What Low Vision Users Expect Robust Solutions Adaptive Interfaces Usable Content
Text Resize
WHO estimates 285 million visually impaired people worldwide. 39 million are blind. 246 have low vision (7.3x as many).
As opposed to the United States population…
Or even Canada’s!
Our job is not to go easy on developers who should know better, but to help foster digital equality for everyone.
»»» So what about the end users???
Web Developers vs. End Users
Visual Concepts
Acuity Limit
Critical Print Size (CPS)
Feasible Print Range
Cost + Technology +
Reader Preference => CPS
To read you need CPS + Word Wrapping
Image of graph of reading speed (vertical) by font size (horizontal)… very simplified.
Is Zoom bad for Everything?
NO! Zoom is great for spot work near the acuity limit
Small Control forms can be zoomed and operated
Zoom just fails for reading.
The reason follows
Why?
Enlarged content presented for users with full sight is not the same as content presented for users with compromised sight.
Specifically
Lack of word wrapping creates semantic discontinuity
Discontinuity creates data loss and noise
Now let’s quantify the data loss and noise
Figure1: A Simple Text Standard Print
Figure 2: Same Text Zoomed with NO Reflow
Same Text Enlarged WITH Reflow
Counting Words
Figure 1: 113 words
Figure 2: 36 words (counting partial words)
Figure 3: 35 words
At a glance, Figure 2 looks as efficient as
Figure 3
Continuity
• Figure 1 (standard print) and Figure 3 (large print wrapped) present contiguous data.
• In of the language in the essay the first word of each line is the immediate successor of the last word on the preceding line.
• This is true for Figure 1 and Figure 3 even though Figure 1 has 3 times the words.
• Even though Figure 3 reduces the quantity of data every word on the page is useful.
Discontinuity and Noise
• Lines are not connected in Figure 2 (Zoom NO Wrap).
• Consider the highlighted line, “Screen magnifier users may.”
• The last visible preceding word is truncated “assisti”
• Between “assisti” and “Screen” are four words and “ve”, the tail of “assistive”.
• This means on line has any real meaning.
• The rest are noise
Data Loss • In the first and third figure there is no noise. • In Figure 2 (NO Wrap).
– Looking at the highlighted line (the signal) we have 4 words – The remainder the disjoint lines, words we have 32 words – Thus only 1 in for words on this view port have meaning as
we read the highlighted line.
• Figure 3 has 35 words, Figure 2 has 36 but • Every word on the Figure 3 (WITH Wrap) viewport is
useful • Only 1/8 are useful in Figure 2 (NO Wrap)
The Burning Question?
• Is zoom without reflow a functional tool for reading?
• Is screen magnification reasonable accommodation?
• Does screen magnification constitute accessibility support for WCAG 2.0 criteria?
Open Discussion
Thinking RWD
Web Developers vs. End Users
Bake SC 1.4.4 straight into your CSS
Thank you!
Photo Credits http://gigaom2.files.wordpress.com/2012/08/shutterstock_97220924.jpg http://udemand.files.wordpress.com/2012/07/14.jpg http://taoofman.com/wp-content/uploads/2012/06/ToM_EnsoCircle.png http://www.information.dk/sites/information.dk/files/media/2009/05/01/20090501-174730-pic-363902257.jpg http://www.namespedia.com/image/Huxley_2.jpg http://www.flickr.com/photos/xurble/196294004/ http://free-illustrations-ls01.gatag.net/images/lgi01a201309211700.jpg http://www.flickr.com/photos/kingdesignchile/9023900039/ http://ministry127.com/sites/default/files/Avoiding%20the%20Traps%20of%20the%20Teen%20Years-blank.jpg http://www.sciculture.ac.uk/files/2013/12/Ignite-Event-Image-2.jpg http://www.abortionmemorial.com/wp-content/uploads/2013/07/blurred-vision.jpg
