W3C home > Mailing lists > Public > public-low-vision-comments@w3.org > January to March 2016

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

From: Detlev Fischer <fischer@dias.de>
Date: Thu, 31 Mar 2016 15:55:34 +0200
To: public-low-vision-comments@w3.org
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"

"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


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

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,

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

"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 in
http://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).

So much for now!

Best, Detlev (mobile accessibility task force)

-- 
---------------------------------------------------------------
Detlev Fischer PhD
DIAS GmbH - Daten, Informationssysteme und Analysen im Sozialen
Geschäftsführung: Thomas Lilienthal, Michael Zapp

Telefon: +49-40-43 18 75-25
Mobile: +49-157 57 57 57 45
Fax: +49-40-43 18 75-19
E-Mail: fischer@dias.de

Anschrift: Schulterblatt 36, D-20357 Hamburg
Amtsgericht Hamburg HRB 58 167
Geschäftsführer: Thomas Lilienthal, Michael Zapp
---------------------------------------------------------------
Received on Thursday, 31 March 2016 13:56:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:23:40 UTC