LVTF Meeting Minutes - November 10th, 2016

Link to minutes, full text also pasted below:
http://www.w3.org/2016/11/10-lvtf-minutes.html erich_manser

Low Vision Accessibility Task Force Teleconference
10 Nov 2016


See also: IRC log


Attendees
Present
      ErichM, Glenda, Jim, Laura, Scott, Shawn, Wayne, Andrew(part)
Regrets
      Alastair, JohnR
Chair
      Jim
Scribe
      Erich
Contents
      Topics
         1. Contrast: Interactive Elements
         2. Contrast: Informational Graphics
         3. Line Length
      Summary of Action Items
      Summary of Resolutions



<allanj> close item 1


<allanj> close item 1


<scribe> Scribe: Erich


<Wayne> present


JA: Hoping we can finalize at least a few of these today


WD: At least to the point of wordsmithing


JA: Start with item# 2, contrast of interactive elements


Contrast: Interactive Elements


<allanj>
https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Contrast_(Minimum)#SC_Text


JA: It seems that we have this exception in the SC text where we talk about
visual presentation
... Medium with Border, could we just call that 3 pixel or greater border?
Then would not need to have one more definition


GS: Open to that


WD: I kind of like the medium, sizes are assigned frequently when doing web
development


GS: I will tell you why I wrote it that way, was trying to use the concept
of large text, and instead of going with large border, went with medium
... Figured that large text and small text was debateable, but wanted the
discussion on pixels to be separate from ratios
... I am fine with changing it


JA: Was trying to be expedient, and could simplify. Fine either way.


LC: Maybe leave it at medium for now, and if WCAG wants to change it they
can


JA: I had a task for last week, about what are the interactive borders
... I tested the browsers, and IE10 was the only to pass on form controls
... They (browsers) failed on enabled controls, forget about disabled
controls


GS: My brain and my gut have not agreed on the correct ratio for disabled
browser controls


WD: Has anyone seen a 3:1 and a 4.5:1 together, and are they different
enough?
... Before we actually submit this, it may be worth taking a look at that


JA: Will put that together today
... Any other objections, have we made our case enough?


WD: Really like the addition at the end


GS: Credit to Alastair for providing the foundation for that


LC: Do we need to remove old proposed description then, and go with
Glenda's?


GS: I would be happy to take that out, but wanted to bring it to the group
first


<Wayne> +1


JA: Any objection to calling this one done, and send to WCAG?


+1


<allanj> +1


GS: no objection


LC: no objection


<laura> +1


RESOLUTION: Working Group agrees that Contrast Minimum for Enabled Elements
is ready to be sent to WCAG


<Glenda> Interactive Element Contrast (Minimum)
https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Contrast_(Minimum)


RESOLUTION: Working Group agrees that Contrast Minimum for Interactive
Elements is ready to be sent to WCAG -
https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Contrast_(Minimum)


Contrast: Informational Graphics


<allanj>
https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Informational_Graphic_Contrast_%28Minimum%29



JA: Lots of work done on this


<Glenda> immediate surrounding background


<Glenda> a 3px area adjacent to the entire length of the perimeter of the
element


GS: One suggestion to add here, have not discussed with Alastair yet, a
definition for "immediate surrounding background", if we don't define, we
will be all over the map


<ScottM> that makes sense


JA: Had posed the question to Alastair last week, and he ran it by his
designers, and they agreed


<ScottM> Are we saying everything has to have a border?


JA: Do we want to add this definition?


LC: yes


+1


<ScottM> or just things that wouldn't pass contrast otherwise?


GS: Everything does not have to have a border


JA: Falls to important information definition, if it's just decoration
doesn't have to


SM: How do we define what needs a border?
... Should the color contrast between the border and the adjacent colors
also need to meet the color contrast requirements as well?


GS: Does not force a border, if the designer picked colors between the
graphical things that are important, no border is necessary
... If it's light gray against slightly darker gray, you're going to need a
border


SM: Working with pie charts that use patterns that could be harder to
distinguish, but they have white borders that are tough to see


<shawn> [ remember we already have SC that says does not rely on color
alone ]


SM: Anticipates more objection if people think we're asking them to put a
border around everything, so we want to make it as clear as possible


<Glenda> example of complex graphic
http://projects.fivethirtyeight.com/2016-election-forecast/



GS: Complex graphic with lots of different colors example, lets
double-check and make sure that the informational piece that we've written
has that alternative available


<allanj> scott, you may want to review Alastair's test page. feed back from
you would be very useful.
https://alastairc.ac/tests/graphic-contrast-test.html



GS: You could have minimalist graphic exactly as it is, but would also need
an alternative conforming version available from the same page


JA: Alastair did a test page that contain some of the same things you were
talking about, if you could review that and give feedback that would be
useful


<Glenda> This is the language in Alastair’s proposed SC for Information
Graphic Contrast (Minimum) “Incidental: Graphical elements that are not
required for the understanding of the graphic, that are pure decoration or
that have an alternative conforming version available from the same page
have no contrast requirement;”


<Glenda> Here is the link to Alastair’s great examples:
https://alastairc.ac/tests/graphic-contrast-test.html



GS: If I look at #8 in Alastair's examples, designers may consider ugly but
people with low vision could see it


JA: How do we feel about this one? We will add the definition in


LC: I will add it


JA: Are there any other objections?


SM: Think I am okay, just playing devil's advocate


JA: Would be important for you to review Alastair's examples, and provide
feedback


SM: OK


GS: One thing I would like in this one, is the incidental bullet point
could be broken in to 2
... "Alternative Conforming Version" would highlight to the designer that
we've given them another way out


LC: will do wordsmithing to make a separate bullet


WD: Also I think we might want to think about techniques, we may want to
have some clear alternative techniques for this issue


<Wayne> reflow:
https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Reflow_to_Single_Column#SC_Text



<allanj> open item 4


JA: Reflow to a Single Column


<Wayne>
https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Reflow_to_Single_Column#SC_Text



JA: We got lots of pushback when we did this, so what's our final wording
here?


WD: Shall I explain each part of it?


JA: Lets see what people think first


<allanj> current wording: Content elements can be arranged programmatically
into a single column with all text in a correct reading sequence. Lines of
text should not be truncated by the viewport unless the spatial layout of
that content is essential to its use. Data tables may retain a multi-column
format, but table cell shall have no lines of text truncated by the
viewport.


JA: My thought, text content should meet these things. Each line is a
separate thought


<AWK> how about: Content can be arranged programmatically and in a correct
reading sequence into a single column.


WD: Can think of two technologies that could do this, but don't know about
the others


<laura> Content can be programmatically arranged into a single column with
a correct reading sequence.


+1


<AWK> Content can be viewed as a single column with all information in a
correct reading sequence.


WD: I think that's perfect


<allanj> Content should not be truncated by the viewport unless the spatial
layout of that content is essential to its use.


AWK: It's really not just text though, what do you do for images?
... Where does the transformation in to single column fall apart that we
would need to have exceptions for it?


WD: We could say lines of text should not require 2D scrolling
... The problem really is not horizontal scrolling, it's really requiring a
person to scroll in two dimensions rather than one dimension


AWK: Are there exceptions where this is done currently? What things fail?
Is it large images, tables, etc?


WD: I should have put some of the examples in
... When you tie the width of a block of text intended to take up the whole
screen to an element beneath that is meant to expand, the expansion can
force the other off the screen


AWK: Data tables are one possible exception where you may have multi
dimension scrolling


<shawn> [ scrolling across a whole table, OK, but not within a table cell ]


WD: correct, but once you're in the data cell, it shouldn't extend beyond
the screen


AWK: How does cell not go beyond, but table does?


WD: Each column of table is one screen width
... Not saying you can't have multiple columns, but columns have to fit on
the screen
... Within that column, you never have to do horizontal scrolling


JA: Would it be possible to include some images that demonstrate this?


WD: absolutely


<Glenda> +1


<Glenda> +q


GS: Wayne had me explore research project he was doing, creating an
environment where I was scrolling left and right, and I had never
understood it so clearly
... I think it would be important for others to experience that


AWK: I am not arguing against this, but trying to figure out how achievable


GS: As we take this forward, not everyone has an understanding of what is
important, so when it gets to next level, we'll be able to represent the
need better if everyone understands


WD: Will add example from Eric for next week's meeting
... Question for Andrew, does PDF example at the bottom look ok?


AWK: Will take a look


JA: Line Length


<allanj> https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Line_Length



Line Length


WD: Really is just the old SC, and action is to move 1.4.8, I would like to
take off "if no user agent", don't think we want to get in to that


<allanj> proposed SC: For the visual presentation of all text, a mechanism
is available such that width is user adjustable between no less than 5
characters and no more than 80 characters or glyphs (40 if CJK).


WD: Basically moving from AAA to level A


<allanj> For the visual presentation of all text, a mechanism is available
such that line length is user adjustable between no less than 5 characters
and no more than 80 characters or glyphs (40 if CJK).


WD: "Width" should be "Line Length"


AWK: Why 5 characters?


WD: That was the original wording
... I think 15 is fine
... 15 is a standard deviation outside the average word length in almost
every language


AWK: It talks about "no more than 80" but does not set the lower limit "no
less than"


WD: It should be something like "width is adjustable down to X characters"


AWK: Is this covered if we get the single column one in anyway?


WD: I think so. Question to Scott, with peripheral field loss would you
like shorter lines?


SM: I am more concerned with keeping track of where I am, rather than what
direction I'm going


<Zakim> shawn, you wanted to say coga? tunnel vision!


JA: So we're saying it needs to be shorter, 80 is not short enough, 5 is
too extreme. Is there some halfway point?
... Tools have changes substantially, and we're trying to make the group
benefitting larger, so what is our reasonable down limit?


<Glenda> Interesting research on comprehension and line length here:
https://en.wikipedia.org/wiki/Line_length



WD: I tested with many browsers and with Acrobat, and I could get to 10%
with no problem


GS: This may end up in area of personalization. May depend on user need,
and task they are trying to complete


WD: Don't think more research is needed. We're just saying that a mechanism
exists that allows you to shrink the line length, not forcing them to use
shorter lines


<allanj> 10% of what


<Wayne> For the visual presentation of all text, a mechanism is available
such that width is user adjustable between no less than 5 characters and no
more than 80 characters or glyphs (40 if CJK).


AWK: The original WCAG says you must be able to resize so that width is no
more than 80 characters, but that 80 doesn't need to be there in this
version now


<allanj> For the visual presentation of all text, a mechanism is available
such that line length is user adjustable between no less than 15 characters


AWK: We're trying to address it so that you can resize it to be as little
as you need it to be


WD: I can't use a mobile phone visually, because I can't get print large
enough to read a word in 3 inch space. I hope we don't have to make
something that will address all the way down to cell phone


<Wayne> For the visual presentation of all text, a mechanism is available
such that line length is user adjustable to no more than 20 characters (10
if CJK)


GS: As we're targeting for low vision, should we set a zone? It is
functional at X magnification, that we're not picking up the beginning
edges or the latter edges, but really the between


<allanj> testing on the wiki, wrapping works well with zoom or browser
width. on mobile, zoom comes from OS, and wiki doesn't wrap with mobile
zoom in Chrome.


LC: Wondering about the testability section - what is the starting
percentage for the viewport?


<Zakim> shawn, you wanted to notes # of words and to say am thinking about
people below 200 as well!


SH: I think we are also considering people who are below 200
... I was also thinking about processing the number of characters. With
mobile, I essentially don't need to resize the viewport, as it's already as
small as it needs to be


<allanj> +1 to # of characters vs viewport width


JA: I agree with that


<shawn> on mobile, don't need to resize the viewport - it;s aleady as small
as it needs to be


<shawn> [ /me also notes that # of characters depends on font size ;-/]


WD: Thinking about what's used in mobile cases for responsive design, and
it is down around 15 to 20 m as I recall, so I think that really might be
alright


<laura> I updated the Tracking Success Criteria Progress Table per today’s
resoution for Contrast: Interactive Elements:
https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Tracking_Success_Criteria_Progress



WD: This week I will look at guidelines on responsive design


<Zakim> shawn, you wanted to ask if reflow covers this enough???


rrsagent: make minutes


Summary of Action Items
Summary of Resolutions
   1. Working Group agrees that Contrast Minimum for Enabled Elements is
      ready to be sent to WCAG
   2. Working Group agrees that Contrast Minimum for Interactive Elements
      is ready to be sent to WCAG -
      https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Contrast_(Minimum)
[End of minutes]
                                                                                       
                    Erich Manser                                                       
                    IBM                                                                
                    Accessibility,                                                     
                    IBM Research                                                       
                    Littleton,                                                         
                    MA / tel:                                                          
                    978-696-1810                                                       
                    Search for                                                         
                    accessibility                                                      
                    answers                                                            
                                                                                       
                                                                                       
                                                                                       
                                                                                       
                                                                                       
                                                                                       
                                                                                       



You don't need eyesight to have vision.