Fwd: Detlev comments

​ Comments from LVTF preceded by @@

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 +0200
To: 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!

​@@ Thank-you​


-------------
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"
​
@@ 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

​@@ ​leaving as is.


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

@@
​The Introduction states "This document... describes what people with
low vision need for
electronic content, tools, and technologies to be accessible.
...
User needs can be met at several levels, including hardware, operating
systems, user agents (such as web browsers), extensions, plug-ins,
assistive technologies, and content. This document does not specify
responsibility for meeting user needs, and it does not set technical
requirements."
​

​​
 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,

​@@
​​
browser features exist to do both of these things. We have an expanded
user need 3.5.1 Element Level Customization. However, link/visited-link is not
part of the list. Perhaps we need to add it.
​ Issue 53 <https://github.com/w3c/low-vision-a11y-tf/issues/53>
 ​​
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...

@@
​ ​
Good to know.
​​
The user needs document is only gathering User Needs.
We will evaluate issues and implementations in the future. This comment
and information will be helpful.
​​

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

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

​@@ A very useful bit of information. Added to ​Issue 50
<https://github.com/w3c/low-vision-a11y-tf/issues/50>
​

So much for now!

Best, Detlev (mobile accessibility task force)

​@@Thank-you for your comments!
Jim​

-- 
Jim Allan,
​ Co-Facilitator Low Vision Task Force​

Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964