happy to scribe today

<laura> Scribe List: https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Scribe_List

<laura> You’re welcome,

<laura> You’re welcome, Shawn.

<AWK> +AWK

<alastairc> +alastairc

+Erich

AWK: first would like to get to the survey first

Survey: https://www.w3.org/2002/09/wbs/81151/20161020/

AWK: sorry for getting agenda out late, did not have much time for the survey

<AWK> relates to https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Reflow_to_Single_Column

AWK: three people have responded, all looking for changes to it

<erich missed several statements>

AWK: Some people go to description for techniques, but really need to go to test procedure

WD: We were taking concept of G57 and making it normative
... Suggests we state explicitly what we want in

AC: Has not been covered in practice by meaningful sequence
... Took out things that are not explicitly hidden by the author. Does not think we necessarily need in the SC text

AWK: Agrees with that. Having lots of trouble with it sounding just like 1.3.2 to me, what it doesn't do is clearly indicate that we're talking about the visual order of the content, and so what we now have as a correct reading sequence is the same as 1.3.2

WD: It doesn't say that, it is different.

AWK: If you have a webpage with content presented on that page, and the sequence affects the meaning, you have to be able to get a programmatically determined sequence.
... The correct reading sequence could be anything. But if I take three columns, the sequence could be anything. Does that make sense?
... So when we say the elements of a document are sequenced so that the elements are in correct reading sequence, it's kind of the same thing, just in reverse. It's not say you need to be able to read this a certain way.
... In order to meet this, I would need to make sure the correct reading order matched the visual reading order.
... It's not saying you need to be able to linearize the entire page.

WD: You can linearize the entire page, provided you know the reading order.
... I think this is the difference between accessibility and accommodation.

<alastairc> Brings me back to: "When the visual elements of a page are presented as a linear sequence they retain a correct reading order."

WD: All we're doing is requiring the programmer to create a situation where we need AI to tell us what was in their head.
... 1.3.2 talks a lot about the bi-directional algorithm.
... It does not say those things should be listed in a reading order.
... We could say add G57 as an appendage to 1.3.2

AWK: Could you give a couple of examples?

AC: I think I can.
... There's an implementation bug in FF about how flex ordering works
... When you're tabbing through, FF will follow the flex order
... If you are linearizing a page from a DOM perspective, that will give you a wrong result
... If you linearize the page using visual presentation, it gives you a different result

AWK: I may need to see the example you're talking about, not making sense to me

<alastairc> http://adrianroselli.com/2015/10/html-source-order-vs-css-display-order.html

AC: Pasted in irc, if you want to see how it's actually working
... CSS and grids will allow people to manipulate the visual order without affecting the DOM

AWK: Why wouldn't this fail 1.3.2?

AC: There's several programmtic orders, with no indication of which to follow

AWK: I think linearization was one of the things we hoped we would get, and I don't think we consistently have

WK: My question is whether this success criteria as-written will address that

WD: It least gives you the opportunity to know what the author's intended sequence is
... There are many ways to order a document, and if there's more than one, which one do you choose

<ScottM> +q

WD: The potential for ambiguity is great, and by simply saying you put it in a reading order as you program, guarantees that this does not come up as a problem. It's not a burden for developers

AWK: I am not arguing against, I just think that what 1.3.2 covers is already included here

AC: I did put an alternative in which includes the linear sequence Andrew is looking for

SM: The problem I run in to from an audit standpoint, is there doesn't seem to be any explicit definition of how you define a reading order
... You have the base reading order, but authors have the ability to change the layout of a page using CSS however they want
... They put up things like simulated modal dialogs, which always appear completely out of order of the DOM
... Maybe 1.3.2 does address this, but end result is you cannot linearize this
... There's this conflict between reading order in the DOM and reading order imposed by CSS, and how do you address that?
... Not sure 1.3.2 quite does
... How do we programmatically tell an AT how to reconcile those things

WD: Here's a use case I run in to a lot. Many with low vision look at the print while listening to the print
... It's very disruptive when what you're looking at, and what you're being read, come at you in a different order. And it happens a lot.
... If we state it that way at the normative level, it may help us anticipate what's coming

AWK: Question for Wayne - if someone is following along visually as content is coming in different ways, is this a fine detailed problem, gross level detailed problem, or both?

<ScottM> I'd say both

AWK: Ex: newspaper website reinforcing the notion most important info is in upper right corner, that would be gross level. Fine level might be if I have a form control, that says Telephone Number with the field, and what one might decide is that it's important to bundle label and instructions together so that you receive both at the same time. Fine level. Is it both, or one or the other?
... In order to meet 1.3.2 you have to be able to look at what you have on the screen and say Yes, this is reflective of this. Not some random assortment of what should be reflected.

WD: We don't really have a test of whether 1.3.2 is doing it or not, because most people lay them out in the order they want them to be naturally
... An example, on our wiki page, if you linearize our wiki page, LOGIN goes all the way to the bottom
... It's still a correct reading order. It's inconvenient, but correct.
... There are cases where you linearize a page, and it does not come out, and it can be the fault of the screen reader.
... Worried we will get technologies that will create a situation where an AT must go in and look at several different places to determine what the reading order is
... The user would need to pay attention to all these things just to know what the reading order is
... Alastair gave one example, and as we develop the web, more examples will come up

<ScottM> +q

WD: Noticed that G57 was the only way to really point out that you meet the 1.3.2 criteria

<Zakim> alastairc, you wanted to talk about neutralising layout

AC: I added a bookmarklet to the list, that was an initial try at having a forced linearization without killing all the styles
... There'd be DOM order and more of a CSS order
... I understand that this might become a set of techniques under 1.3.2, but thinks worth proposing as a SC first so that people realize the importance

SM: This is similar to problem you have with PDF's where a tag system was added later on for accessibility, and a reflow sequence inherent to the PDF itsefl, and if the two are not sequenced you have an interesting situation
... With the web, you can have a layering which the DOM doesn't express, and really no way of reconciling those things
... In order to meet the criteria, the DOM has to be in order
... Not a huge problem the majority of the time, but occassionally the authors cannot put the DOM order in the reading order
... None of the AT's at the moment support layering, so you're ending up with a huge document
... There is a conflict, and we have to be more explicit about the DOM needing to reflect the reading order
... Or find a way where we can use CSS and get the AT vendors to support so that we don't have this conflict
... We have arguments with customers who come back and say they can't change the DOM, and all we can say to them is that it's a violation
... It would be nice if we could push a way of making this work, explicitly
... People will move away from using DOM to define what the layout of a page is going to be.

AWK: Clarifying earlier point with PDF

SM: If your tags don't align with the objects that you have in your reading order, or they are out of order, you get weird things that happen
... Most of the time, the advice that we give and i've seen Adobe provide, is that these things must match up. If you have explicity defined, the tag structure needs to reflect that
... If you're missing some content in the tags, it will sometimes just get strange, as it will be handled differently
... Sometimes if you have a tag structure that is completely bizarre, I've had times where I've had to erase and start over.

AWK: Same as what we're talking about?

SM: Similarities with PDF. You can end up with a situation, if you have a paragraph and reading order is split in 2 parts, if the tags are created so you have a tag that encompasses an entire paragraph, if that tag doesn't get in to more detail, most AT's are going to fall down to reading the reading order
... The most common thing we see is words can be broken in to 2 pieces.
... To fix, we treat each word as it's own object
... or you can have a huge block of tags, which doesn't happen quite as often
... Similarly on the web, it's not quite as bad, but the problem is that CSS is going to define how the page is laid out visually
... You can have a sidebar, maybe that's an important piece of information, you can set up your DOM so it appears after the navigational stuff on the left
... So the question becomes, what is the intended reading order supposed to be?
... You can sometimes guess, but programmatically how do we determine? Trust the DOM?
... Right now, we're taking out the CSS completely and trusting the DOM

WD: Even in W3C technologies and HTML, we're not going to just have the DOM anymore, we're going to have web components dropped in there.
... Not clear how that's going to go with the rest of the program.
... Today we're getting an indication of how those of us with visual disabilities have felt about how 1.3.2 has worked for us.
... We could make it a level AA to make the distinction
... It seems like a guide that would be very useful for this HTML change
... Trying to state it in terms that authors can control, not about user agents

<Zakim> alastairc, you wanted to talk about volunteering to carry on with this SC and add a test case.

AC: Volunteering to take up this SC

AWK: Have not heard anything not covered by 1.3.2
... If we have a problem that is user agent related, we can't do anything about it, so authors are correct focus
... If it is already covered by 1.3.2, maybe clarifications in understanding or techniques are needed
... If it's something else, I still don't understand what that thing is, suspect I'm not alone
... Linearization not required unless you go to 1.4.8

AC: Think I can come up with test case to highlight the differences

SM: Everything we're trying to do may be in 1.3.2, but there's something about it that's missing

Believe I am muted

Informational Graphic Contrast – 4.5:1 or something else?

<AWK> EM: Was looking at this issue and thought that 4.5:1 was ok but wanted to clarify

<Wayne> +1

<AWK> Laura: agrees

<AWK> EM: was also looking at borders - an they be required?

<AWK> ... hard to read when content is not clearly delineated from the background

<AWK> ... can that be included as a recommended practice?

<AWK> Laura: Could be a technique

<AWK> EM: Borders would be for each wedge of a pie chart for example

<laura> New Techniques: https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Informational_Graphic_Contrast_(Minimum)#New_Techniques

<ScottM> +q

<laura> Informational Graphic Contrast (Minimum): https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/

SM: The SC is limiting itself to ratio
... Not disagreeing, we do need these kinds of things, if we're talking about the contrast itself between two kinds of things, it's fine
... How do we address more broadly other types of visual impairment. I think they're related, but separate
... WOuld need to decide what other kinds of enhancements we need
... If turning on HC, and suddenly everything has a border, in certain cases that can seem like almost too much
... COGA group would likely have much to say as well

WD: This is a tough one
... In some ways I think we can do the contrast ratio, but cannot do borders

<Zakim> alastairc, you wanted to ask if we could we take the approach of contrasting the element as a whole rather than colour specifically?

AC: We already have use of color which generally helps for that sort of thing. When you look at best practices, the use of patterns can help with those distinctions.
... The aim of the current contrast minimum and interactive contrast, to make sure there is contrast, we're not trying to define that everything must have a border, but that you can distinguish one element from another.
... Current color guideline can really help for this kind of thing.

<laura> The 2 contrast SCs were combined at one time.

WD: Just thinking contrast, I think this could be a good SC just focusing on contrast. I know we've worked on Informational Graphics, but being more specific on this, I think we'd have to be really careful with what we excluded on this
... In talking earlier, part of the challenge with this one, was just that - trying to break informational graphics out from graphics in general

<AWK> EM: this is great feedback and will continue to work on it

SM: Each element of the informational graphic has to be distinguishable from every other. You can still derive the same information from that graphic as you could if could see the colors. How you go about that is a matter of debate

Using User Settings – discussion

<ScottM> no pressure! :)

<AWK> EM: Question from up at IBM

<AWK> ... was using user settings going to address for high contrast issues

<ScottM> brb

<AWK> Wayne: background images disappear in HCM

<AWK> ... that's one of the big problems

<AWK> people put important graphical content into background images

<AWK> ... and that's a problem frequently

<AWK> Laura: mentions F3 and how it may be removed

<laura> Something to be aware of is that WCAG has historically had F3: Failure of Success Criterion 1.1.1 due to using CSS to include images that convey important information.

<laura> However, F3 is under discussion to remove the HCM requirement so it would NOT be a failure.

<laura> A yet to be written technique for HCM has been proposed but not written.

<laura> https://github.com/w3c/wcag/issues/80

<laura> bye. Thanks all.

Trackbot, end meeting

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/shawn better? :)//
Succeeded: s/2 color SCs were combined at one time./2 contrast SCs were combined at one time./
No ScribeNick specified.  Guessing ScribeNick: erich_manser
Inferring Scribes: erich_manser
Default Present: Shawn, Andrew(AWK), Wayne, JohnRochford, Laura, ScottM, AWK, alastairc, Erich
Present: Shawn Wayne JohnRochford Laura ScottM AWK alastairc Erich
Found Date: 20 Oct 2016
Guessing minutes URL: http://www.w3.org/2016/10/20-lvtf-minutes.html
People with action items: 

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