LVTF Meeting Minutes 10/20/2016

Link: http://www.w3.org/2016/10/20-lvtf-minutes.html


Plain text minutes are pasted below:

Attendees
Present
      Shawn, Wayne, JohnRochford, Laura, ScottM, AWK, alastairc, Erich
Regrets
Chair
      Andrew(AWK)
Scribe
      erich_manser
Contents
      Topics
         1. Survey: https://www.w3.org/2002/09/wbs/81151/20161020/

         2. Informational Graphic Contrast – 4.5:1 or something else?
         3. Using User Settings – discussion
      Summary of Action Items
      Summary of Resolutions



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
                                                                                       
                    Erich Manser                                                       
                    IBM                                                                
                    Accessibility,                                                     
                    IBM Research                                                       
                    Littleton,                                                         
                    MA / tel:                                                          
                    978-696-1810                                                       
                    Search for                                                         
                    accessibility                                                      
                    answers                                                            
                                                                                       
                                                                                       
                                                                                       
                                                                                       
                                                                                       
                                                                                       
                                                                                       



You don't need eyesight to have vision.