W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > July to September 2013

Re: Sub Discussion of Text Zoom vs. Browser Zoom (today's EO teleconf)

From: Wayne Dick <wayneedick@gmail.com>
Date: Mon, 5 Aug 2013 13:31:50 -0400
Message-ID: <CAJeQ8SCgC7AtK0WUQappQQkQQNWsno2Ttac2i5g-ue0D9=3AfQ@mail.gmail.com>
To: Alan Chuter <achuter1@gmail.com>
Cc: "EOWG (E-mail)" <w3c-wai-eo@w3.org>, Denis Boudreau <dboudreau@accessibiliteweb.com>
Content that does not word wrap effectively when a browser enables
text-only enlargement is an accessibility failure in reality.  It does
not support reading.  The criterion states explicitly, "text can be
resized without assistive technology up to 200 percent without loss of
content or functionality."

The tricky part comes with the phrase "without loss of functionality".
 Is unwrapped text functional?  Well let's analyze that proposition.

Now if we enlarge 10pt font to 20pt font we have about 15-25 lines
depending on line height.  If we have word wrapping we have all of
these lines filled with useful information.  If we do not have word
wrapping only one of these lines, the one the user is reading, has
useful information.  The remainder are truncated lines of noise.  That
means, the noise to signal ratio is between 15:1 and 25:1.  This
degradation of signal quality occurs even before the user attempts to
navigate the page.  Horizontal scrolling is always challenging.  It is
easy to drift up or down, and changing from one line to the next is
always a challenge.  The greatest cost is in concentration.  If one is
focused on staying on the current line or finding the next, the actual
problem of understating the text can easily be impossible.  So, the
claim that failure to word wrap is not a failure makes it possible for
vendors who cannot support a necessary function, reading, to claim
accessibility.

Let us take the example of moderate low vision.  The operational
definition of low vision (Legge, "The Psychophysics of Reading") that
is relevant in this case is: an uncorrectable vision loss that
prevents perception of 10pt text at a distance of 40cm (16in). Stated
another way, a person with low vision cannot perceive the optimum font
size for normal readers at a comfortable reading distance. A person
who could perceive 200% enlargement of 10pt text, namely 20pt text, at
close to normal distance would be considered to have moderate low
vision.  Now, this print size may not be optimum, but it will lie
within the acuity limit of the person with moderate low vision.  This
is an important group because it is the majority group of people with
visual impairment.  The decision to exclude failure to word wrap as a
failure case for SC 1.4.4 simply removes reading web content as a
practical option for this group.









On 8/5/13, Alan Chuter <achuter1@gmail.com> wrote:
> I have to agree with you and to express my amazement at the
> implication that requiring the user to use a horizontal scroll bar is
> acceptable. This would make reading text impractical in a real
> situation.
>
> Maybe rather than shortening the text, someone could produce a short
> video of a user having problems with this, even just a screen capture
> with descriptive voice over. I'm not able to do this, but I imagine it
> wouldn't be too difficult. It would demonstrate the problem in just a
> few seconds.
>
> As for the Easy Checks [1] (I hope I'm looking at the right draft), it
> would be useful to also include a screenshot with horizontal
> scrollbars. The text "Some people with disabilities cannot read text
> that requires horizontal scrolling" doesn't actually say why. This is
> explained further down under "What to check for," but maybe it would
> be clearer to put it in the main section. It's obvious to me, but
> probably won't be to many page designers.
>
> regards,
>
> Alan
>
> [1] http://www.w3.org/WAI/eval/preliminary#zoom
>
>
>
> On 26 July 2013 18:05, Denis Boudreau <dboudreau@accessibiliteweb.com>
> wrote:
>> Hi all,
>>
>> As agreed, I've made my case for the Understanding document for SC 1.4.4
>> to explicitly support text zoom in a HTML context because I feel it
>> spectacularly fails to do so right now. It's probably much longer than it
>> should, but I'm hoping this helps to build a strong case. Maybe you guys
>> will be willing to add to it, or tersify the heel out of it! *grin*
>>
>> Whatever makes it better and more convincing:
>> http://www.w3.org/WAI/EO/wiki/Easy_Checks_Comments#Sub_Discussion_of_Text_Zoom_vs._Browser_Zoom
>>
>> Again, many thanks to Wayne for helping me see the broader picture here.
>>
>> /Denis
>
>
>
> --
> Alan Chuter
> achuter1@gmail.com
>
>
Received on Monday, 5 August 2013 17:32:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:56:01 UTC