W3C

- DRAFT -

Low Vision Accessibility Task Force Teleconference

09 Feb 2017

See also: IRC log

Attendees

Present
allanj, Shawn, ScottM, Glenda, Laura, Wayne, steverep
Regrets
Alastair, Glenda_(partial)
Chair
Jim
Scribe
allanj, glenda, Shawn

Contents


<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.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2017/02/09 18:03:39 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/for us to process due to lack of threading/for some of us to process/
Succeeded: s/others are at the beginning end of low vision./some are at other end of low vision./
Succeeded: s/Screen magnification software is not a viable solution for some people. Adaptive strategies fall short/Screen magnification software is not a viable solution for some people./
Succeeded: s/hitnking that hor scolling/ thinking that horizontal scrolling/
Succeeded: s/Wayne's reseach on horoztonal scrolling/When I participated in Wayne's research/
Succeeded: s/Lineariztaion/Linearization/
Succeeded: s/I want to be able to change the leading on content in PDF/e.g., user needs to change the leading on content, that is in PDF/
Succeeded: s/lets cover 80%/ /
Succeeded: s/not picking/now expanding it and picking/
Succeeded: s/excellent understanding document/excellent understanding document that explains the broader issue/
Succeeded: s/understandability, to explain that the SC is to make it understandable for testing/Understanding doc, to explain that the SC was worded that way for testing, but really users need range of fonts, tec./
Found Scribe: allanj
Inferring ScribeNick: allanj
Found Scribe: glenda
Inferring ScribeNick: Glenda
Found Scribe: Shawn
Inferring ScribeNick: shawn
Scribes: allanj, glenda, Shawn
ScribeNicks: allanj, Glenda, shawn
Default Present: allanj, Jim, Shawn, ScottM, Glenda, Laura, Wayne, steverep

WARNING: Replacing previous Present list. (Old list: Jim, JohnR, Laura, Wayne, Scott, Glenda, Marla, JohnRochford)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ 

Present: allanj Shawn ScottM Glenda Laura Wayne steverep
Regrets: Alastair Glenda_(partial)
Found Date: 09 Feb 2017
Guessing minutes URL: http://www.w3.org/2017/02/09-lvtf-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]