RE: comment on Accessibility Requirements for People with Low Vision ed. draft 16 March 2016

Thank you for the comments. The Low Vision Task Force responses are
inline below, prefaced with LVTF:

From: Detlev Fischer <fischer@dias.de
<fischer@dias.de?Subject=Re%3A%20comment%20on%20Accessibility%20Requirements%20for%20People%20with%20Low%20Vision%20ed.%20%20draft%2016%20March%202016&In-Reply-To=%3C56FD2C56.8020602%40dias.de%3E&References=%3C56FD2C56.8020602%40dias.de%3E>>Date:
Thu, 31 Mar 2016 15:55:34 +0200To: public-low-vision-comments@w3.org
<public-low-vision-comments@w3.org?Subject=Re%3A%20comment%20on%20Accessibility%20Requirements%20for%20People%20with%20Low%20Vision%20ed.%20%20draft%2016%20March%202016&In-Reply-To=%3C56FD2C56.8020602%40dias.de%3E&References=%3C56FD2C56.8020602%40dias.de%3E>Message-ID:
<56FD2C56.8020602@dias.de>

I think overall this is a very good and clear text!

-------------
Editorial comments
-------------

Typo and expressions: 3. User Needs

"User needs varying widely across people who have low vision"
should probably be:
"User needs vary widely across people who have low vision"

LVTF: fixed

"for example, when they are more fatigued"
to be fatigued seems odd - when they experience more fatigue"?
...but then I am not a native speaker

LVTF: fatigued is appropriate

-------------
Substantial comments
-------------

Scope
When I read  "User Need - Brightness: Users can set the overall
brightness of a display", I wondered whether this document and
requirements are written with the intent to become (part of) a WCAG
extension  - because display brightness is certainly not something web
authors can influence.

LVTF: While the task force is part of WCAG (now AG), we focused on the
USER need without regard to specific guidelines.

Contrast
" User Need - Contrast: Users can set the background color and the text
color from the full color spectrum."

Would it be useful to include the option of setting the colour of links
/ interactive text? These may not be discernable if their colour cannot
be adapted to chosen bg colour,

LVTF: document updated Issue 50
https://github.com/w3c/low-vision-a11y-tf/issues/50

"User Need - Text Size: Users can change the text size (font size) of
all text, without zooming the entire interface."

Reg. "all": At least in mobile scenarios, this is often difficult
without breaking the layout, e.g. when a horizontal menu that fits into
the screen width would have to wrap, moving all content down or worse,
creating overlaps.

I think there is a trade-off, and many grid-based mobile app layouts
will have a hard time accommodating incremental test-only resize. Some
platforms (BBOS 10) had "solved" the problem (with BB, on the hub) by
using ellipses and truncate text content that does not fit, which also
creates a problem. It can be acceptable or not, depending on content and
the amount of truncation.

One option may be to focus the requirement on _text content_ and have an
exception for stable positioned text controls. So in a mail app, the
requirement would apply for mail title and body text, new text in
replies, etc., but not for controls (send, save, back, cancel, etc)

The argument for that would be that users learn to expect these as
quasi-permanent control features of an app at predictable positions, so
there is actually less need to read controls. Zoom might be used for
familiarisation with those controls, after that the advantages of not
increasing text size of controls might outweigh the disadvantages of a
changing layout through reflows. Just food for thought, though...

LVTF: thank you for this.

"Users can change the font face (also called font family or typeface) of
all text"
"Users can change the text style (underline, italic, bold) of blocks of
text."

Again, my context is mobile use, and the issue is related to the above -
some fonts are wider so on controls they might either lead to cut-off
text or wrapping and displacement of controls. Similar exception?

LVTF: this is addressed by 3.7.1 Seeing All Interface Elements
<http://w3c.github.io/low-vision-a11y-tf/requirements.html#seeing-all-interface-elements>

One particular thing that I found missing is the ability to customise
grids and leading lines. In our tests with low vision users, we often
had the issue that light gey grids weren't perceived and items not
allocated accordingly.
Say, in a Samsung calendar grid, the salient info can easily be
allocated to the wrong day (see Fig 10
inhttp://www.incobs.de/tests/items/tablet-tests-mit-sehbehinderten-nutzern-gebrauchstauglichkeit.html
)

A similar issue is controls that have a large offset from the label.
Moving the visible section (e.g. on a mobile device) to bring related
control or label in view is much harder if there is no visible guiding
line helping in making the link (e.g. (on Windows Mobile). Web  / App
developers may be required to ensure 4.5:1  contrast of leading lines /
grids where these aid perception/navigation (this could presumably also
be a system-level setting where contrast of grids and dividing / leading
lines can be increased).

LVTF: this is covered in 3.6.2 Proximity of Related Information
<http://w3c.github.io/low-vision-a11y-tf/requirements.html#proximity-of-related-information>
and 3.1.3 was updated to include this information see Issue 54
https://github.com/w3c/low-vision-a11y-tf/issues/54


So much for now!

Best, Detlev (mobile accessibility task force)


-- 
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 <(512)%20206-9315>    fax: 512.206.9264
<(512)%20206-9264>  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964