<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

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