Why Browser Zoom Sucks for Low Vision Users
Upcoming SlideShare
Loading in...5
×
 

Why Browser Zoom Sucks for Low Vision Users

on

  • 1,780 views

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

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?

Statistics

Views

Total Views
1,780
Views on SlideShare
1,776
Embed Views
4

Actions

Likes
1
Downloads
9
Comments
0

1 Embed 4

https://twitter.com 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Story. Building consistency in our methodology. Looking at Success Criteria, hashing out violations vs. best practices. Reaching agreements. Then SC 1.4.4.
  • What SC 1.4.4 truly asks for is 200% magnification. But on lvl AA… so what does this mean to low vision users?
  • According to research, most low vision users would require a 300% magnification level.
  • Accessibility testing can never fail when we only test for browser zoom. So why bother with SC 1.4.4? Scroll bars are unacceptable.

Why Browser Zoom Sucks for Low Vision Users Why Browser Zoom Sucks for Low Vision Users Presentation Transcript

  • Denis Boudreau Deque Systems, Inc. db@deque.com @dboudreau SUCKS Wayne Dick CSU Long Beach waynedick@knowbility.org 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