why browser zoom sucks for low vision users

Post on 08-May-2015

1.950 Views

Category:

Technology

2 Downloads

Preview:

Click to see full reader

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

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

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

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

top related