See also: IRC log
<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
<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)
<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
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
<laura> bye
<shawn> shawn: I've not had problems with this. As long as I get reflow, then I can change the viewport size. On mobile, don't need it any smaller. So my question is: Do you know of any situations where people cannot get the short line length they need? If not, then maybe we say that while this is a user need, it's covered in existing enviroments, so we put it lower prioirty to bother with for 2.1. The
<shawn> issue I can see is if developers can disable viewport revizing -- or if a new format/tool didn't provide it.
<shawn> rrsagent: make 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) No ScribeNick specified. Guessing ScribeNick: erich_manser Found Scribe: Erich WARNING: Replacing previous Present list. (Old list: alastairc, Laura, Jim, Shawn, ErichM, Scott, JohnRochford, Glenda, wayne) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ Laura, Shawn, ErichM, Glenda, Jam, Scott, Wayne Present: ErichM Glenda Jim Laura Scott Shawn Wayne Andrew(part) Regrets: Alastair JohnR Found Date: 10 Nov 2016 Guessing minutes URL: http://www.w3.org/2016/11/10-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]