Minutes: Low Vision Task Force 9 Feb 2017 telecon

source: https://www.w3.org/2017/02/09-lvtf-minutes.html

Low Vision Accessibility Task Force Teleconference 09 Feb 2017

See also: IRC log <http://www.w3.org/2017/02/09-lvtf-irc>
Attendees
Presentallanj, Shawn, ScottM, Glenda, Laura, Wayne, steverepRegretsAlastair,
Glenda_(partial)ChairJimScribeallanj, glenda, Shawn
Contents

   - Topics <https://www.w3.org/2017/02/09-lvtf-minutes.html#agenda>
      1. Review SCs from WCAG
      <https://www.w3.org/2017/02/09-lvtf-minutes.html#item01>
      2. enlargement without word wrapping is not accessibility support
      <https://www.w3.org/2017/02/09-lvtf-minutes.html#item02>
      3. New SC survey
      <https://www.w3.org/2017/02/09-lvtf-minutes.html#item03>
   - Summary of Action Items
   <https://www.w3.org/2017/02/09-lvtf-minutes.html#ActionSummary>
   - Summary of Resolutions
   <https://www.w3.org/2017/02/09-lvtf-minutes.html#ResolutionSummary>

------------------------------

<allanj> Laura #78 Override

<allanj> Erich #76 Printing

<allanj> Wayne #75 Metadata

<allanj> Glenda #10 Interactive

<allanj> possibly for Graphics Contrast (#9, #100), Linearization (#58,
#89), Resize Content (#77),

<allanj> scribe: allanj

<laura> https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info

<scribe> scribe: glenda
Review SCs from WCAG

Shawn - can we have a summary of content that is difficult for some of us
to process.

Wayne - we are missing LV SC, so consuming this large stream of content is
exponentially difficult for people with low vision.

<steverep> Could someone please provide me the WebEx password?

Wayne - concerned about tone of conversation on lists. Concerned about 8
out of 10.

<Wayne> I think AG WG is a hostile working environment

Jim: you wrote about dropping a propsed SC Enlargement of Text. Were you
dropping that because of hostility?

Wayne: No. I read accessibility support.
... I would like a resolution that LVTF deems that enlargement without word
wrapping is not accessibility support.

Shawn: Wayne needed to drop being the manager of SC Enlargement of Text,
but he still thinks it is a requirement for LV
enlargement without word wrapping is not accessibility support

Wayne: Any SC that has to do with reconfiguring typography to accomodate
low vision, enlargement without word wrapping does not constitute
accessibility support.

Shawn: Let’s list specific SC that this applies to.

<laura> Issue 58 linearization

Wayne: For example: Letter spacing, Word spacing, Font family, all of the
Resizing and Reflow SCs

<shawn> Shawn: We already have in place an SC related to not horizontal
scrolling, yes?

allanj: Linearization 58 and Resize Content 77 are both in github pull
request with horizontal scrolling

shawn: we are including good horizontal scrolling requirements in each
proposed SC that needs it.

Wayne: I just need a statement from LVTF (a fact) - enlargement without
word wrapping is not accessibility support

shawn: we have that in user requirements

Wayne: I think the problem is people are still interpretting “accessibility
support” as a screen magnifier that requires horizontal scrolling.

<shawn>
https://www.w3.org/TR/2016/WD-low-vision-needs-20160317/#rewrap-for-one-direction-scrolling

<shawn> User Need - Rewrap: Blocks of text rewrap so that only one
direction of scrolling is needed, e.g., for left-right and right-left
scripts (languages), usually vertical scrolling and not horizontal
scrolling.

Wayne: we need to break the false assumption that horizontal scrolling is
okay for LV

<allanj> wayne: word wrap is a necessity no matter the size of text.

<allanj> wayne: ... or size of the block of text. even menus, single words.

Wayne: my research shows that the horizontal scrolling problem is leading
to a very significant barrier for low vision (at a rate of 50 times harder
per page)

shawn: I’m trying to find a solution. what blocks of text? discussing this
concept in menu items.

Wayne: every time 4 or 5 times day, a menu runs off the page

<allanj> wayne: authors could put hyphenation

Wayne: a very large majority of the WCAG think horizontal scrolling is not
a big deal

ScottM: look how responsive design works, trying to represent a page on a
tablet, design makes sure there is no horizontal scrolling. Nobody
considers it to be a design problem to solve for a tablet or smaller. But
for low vision, horizontal scrolling is inappropriately considered to be
okay. It is the same technique to solve horizontal scrolling for LV (as is
currently being used in responsive design). This is a valid position and
important position for the

LVTF to say.

<allanj> +1 Scott low vision horizontal scrolling comparison to tablet or
mobile design.

<shawn> [ good point that this is relatively "easily do-able" ]

+1

<laura> for example push back check the pull request for reflow:
https://github.com/w3c/wcag21/pull/89

laura: example of pushback is on reflow. on pull request for TPG saying it
should be handled by UserAgents https://github.com/w3c/wcag21/pull/89

<shawn> Glenda: I suuport us having a resultion. It is to be expected that
we'll have push back. OK to get questions. NOw deeper understand importance
or resolution

steverep: accessibility expert with low vision working in a large .com
... wayne what do you see as the upper bound for magnification? When is it
time to switch to a screen reader?

wayne: I’ve worked it out to 700%
... alastair discovered the measurement to use is css pixels

<Wayne> http://nosetothepage.org/Fitz/2dScroll.html

wayne: the answer is 700% to 800% (to steverep’s question)
... see research that supports 700% - 800% at
https://github.com/w3c/wcag21/pull/89

steverep: describing his low vision and use of zoomtext and NVDA. we must
define the upper bound of magnification. we need to define what text
elements this applies to. I’m interested in reading Wayne’s research.
... continuous reading when horizontal scrolling was very difficult that is
why I switched to NVDA for many things

shawn: Note - we want to address a range of people with low vision. Some
have extreme low vision and some are at other end of low vision.
... is using line spacing as my main technique (and zooming, text size,
font)

allanj: magnification is not the magic bullet. we are doing a disservice to
people who need magnification without horizontal scrolling.

<Zakim> shawn, you wanted to dream of EO piece on screen mag not meet some
needs

allanj: I think a resolution about accessibility support requiring
magnification without horizontal scrolling would be good.

shawn: this is a point of misunderstanding. it would be so nice to have an
EO piece to help clear up the myth about magnification with horizontal
scrolling being okay.

wayne: we have a diverse representation of low vision users here in this
LVTF.

<shawn> "Screen magnification software is not a viable solution for some
people." http://www.tader.info/understanding.html#atno -- links to "Survey
respondents commented that horizontal scrolling with screen magnification
software made them nauseous, disoriented, and frustrated."

+1 to this research finding from
http://www.tader.info/understanding.html#atno — nauseous, disoriented, and
frustrated

ScottM: magnification is not the magic bullet. I’ve been LV my whole life.
I’ve trained many LV people. Vast majority aquire condition later in life.
Mindset of what they are willing to put up with, is different. Adaptation
techniques.
... looking at how Responsive Design can work in harmony with LV needs may
be the universal design angel
... try to avoid setting an upper limit.

<Wayne> The Low Vision Task Force or the Accessibility Guidelines Working
resolves that: Enlargement without word wrapping does not supply sufficient
accommodation to qualify as accessibility support for people who need
enlargement to read.

ScottM: you have to be extremely careful in setting these limits because
the range of needs is so diverse

<shawn> Glenda: When I participated in Wayne's research... I went from
thinking that horizontal scrolling was just annoying to experiencing

nauseous, disoriented, and frustrated, inability to comprehend dense text
without reading it multiple times

<allanj> proposed resolution: enlargement without word wrapping is not
accessibility support

+1

<shawn> [ ... rewrap so that only one direction of scrolling is needed,
e.g., for left-right and right-left scripts (languages), usually vertical
scrolling and not horizontal scrolling. ]

<ScottM> +1

<laura> +1

<Wayne> +1

<allanj> +1

*RESOLUTION: Enlargement without word wrapping is not accessibility
support.*

<shawn> +1

steverep: I’m glad this is a diverse group of low vision people

<ScottM> SteveVision (tm)
New SC survey

allanj: is issue #10 ready for pull request?

yes, go with it as is right now

allanj: will put #10 on a pull request for SC survey

open item 1

<laura>
https://www.w3.org/WAI/GL/wiki/Brainstorming_Short_Name_Ideas_for_Issue_78

<laura> https://github.com/w3c/wcag21/issues/78

allenj: pull request for 77 Resize Content
https://github.com/w3c/wcag21/issues/77 and 58 Linearization and 9 Graphic
Contrast https://github.com/w3c/wcag21/issues/9 are ready to go

shawn: what is needed is for authors to provide content in a technology
that allows users to change these specific things listed in 78
https://www.w3.org/WAI/GL/wiki/Brainstorming_Short_Name_Ideas_for_Issue_78

allanj: this was to help the authors not to block “ability to override”

shawn: e.g., user needs to change the leading on content, that is in PDF

laura: you can change leading in VIP tool

shawn: but it won’t open all PDFs
... VIP won’t open files with form fields, signature and won’t print

wayne: my concern is this proposed SC 78 is too limited
https://github.com/w3c/wcag21/issues/78

<Wayne> Letter 1.2, Word 1.6

<allanj> I believe that was supposed to be Letter 0.12, and word 0.16

<allanj> glenda: I oversee 50 experts. I need set numbers in order to test.

<shawn> Glenda: currently work with 50+ accessibility experts. for
consistency in testing, need to create a repeatable methodology. I'm
willing to set some numbers. was 200%, now expanding it and picking up more
people. something measureable

<allanj> ack: g

wayne: the testability of https://github.com/w3c/wcag21/issues/78 needs to
test all colors. A way to do that is to simply choose any 2 colors that are
visible to the tester and not currently used on the page…and test against
those.
... font family of Verdana should not be in the SC text.
... it should be in a testing or failure technique
... how can we sell this to developers? They understand when “it does not
work with keyboard”…but why do you need Verdana?

allanj: we got pushback from developers, saying you can’t make us figure
out what font to choose. Deveopers did not know how to meet the SC without
something more specific

shawn: what if we cover this in the Understanding doc, to explain that the
SC was worded that way for testing, but really users need range of fonts,
tec.
... i’m comfortable with the current wording with an excellent
understanding document that explains the broader issue

wayne: I can agree with that

allanj: we removed the colors of black/white. can we remove Verdana?
... we have research and limits that require the measurement on height,
letter-spacing and word-spacing

wayne: verdana is a good one to test with…but this should be in testability
not in SC text

<ScottM> “I reject your reality and substitute my own!” :p

should we say the font-family needs to be wide, or that it really needs to
allow any font-family you need

<Zakim> shawn, you wanted to say that current wording does not give a
requirement for authors to provide content in a technology that allows
users to change font, color, spacing

allanj: it needs to be any font-family you need
... ah, the key is “that current wording does not give a requirement for
authors to provide content in a technology that allows users to change
font, color, spacing”
... is this a new SC that we need?
... what if we removed the word webpage? and we take the “technology” out?

wayne: take hypens out of line-height, letter-spacing and word-spacing

shawn: if technology is html then the user can change these things, with
that technology on a desktop or laptop (they can do it).
... the user may have to pick a certain user agent (like a browser on
desktop)
... a PDF with a form is going to still be inaccessible today

<allanj> Laura: there will be lots of push back

<shawn> and the point is AUTHOR provides in format that allows user to do
this

<shawn> [ I wonder if "is caused by overriding:" ought to be "is caused by
user overriding:" -- phrase needs a subject ]

shawn: thanks for everyone who is participating and following all of this
in detail. Because it is impossible to read these threads.

wayne: agreed.

allanj: I may take metadata

<laura> I created a Wiki page for Results from Bookmarklet Tests

<laura>
https://www.w3.org/WAI/GL/wiki/Results_of_Bookmarklet_Tests_for_Issue_78

allanj: printing and blocks of text needs some work

<shawn> scribe: Shawn

shawn: originally the point was e.g., user changes CSS and it prints that
way. then morphed to zoom. is the first point still kept.

?

<allanj> authors need to provide content in a format that the user can
change font, spacing, color and printed with the changes

Authors provide content in format/technology where users can change font,
color, spacing (and maybe other) and print it.

<allanj> trackbot, end meeting
Summary of Action Items Summary of Resolutions

   1. Enlargement without word wrapping is not accessibility support.
   <https://www.w3.org/2017/02/09-lvtf-minutes.html#resolution01>

[End of minutes]

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