W3C home > Mailing lists > Public > public-low-vision-a11y-tf@w3.org > October 2016

LVTF Minutes October 13th 2016

From: Erich Manser <emanser@us.ibm.com>
Date: Thu, 13 Oct 2016 12:33:41 -0400
To: "Low Vision Task Force" <public-low-vision-a11y-tf@w3.org>
Message-Id: <OF65F2C099.BDDB3A69-ON8525804B.005ABC61-8525804B.005AF996@notes.na.collabserv.com>

Hello Everyone,
Minutes of today's LVTF meeting can be found via hypertext at:
http://www.w3.org/2016/10/13-lvtf-minutes.html


And as plain text pasted below this message.

Attendees
Present
      Alastair, AWK, Shawn, Glenda, ErichM, Laura, alastairc, ScottM, Wayne
Regrets
Chair
      AWK
Scribe
      Erich
Contents
      Topics
         1.	Updates from last week’s call
      Summary of Action Items
      Summary of Resolutions



<AWK> +AWK


<AWK> +Erich_Manser


<Glenda> +Glenda


<Erich> Happy to scribe


<AWK> SCribe: Erich


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



Updates from last week’s call


<laura> Minutes: https://www.w3.org/2016/10/06-lvtf-minutes.html



<AWK> light agenda today, will be more granular next week. Review of last
week's minutes


<AC> Update on SC Size of All Elements, posted an update to the list


<AC> Trying to get my head around Reflow to Single Column


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



AWK: On SC Progress table, we have Size of All Content, Text Size and
Reflow to Single Column, those are the 3?


AC: Yes
... Believes SC is covered by Size of All Content, Reflow to Single Column,
with Text Size from WCAG 2.0
... Text size one is difficult to achieve as a web author. increasing text
size up to web max is difficult


AWK: Size of All Content now is restricted to 400%


AC: Depends on varying factors


Glenda: Variable up to AAA


AWK: Sees "needs more work" among open items


AC: They appear to have been addressed


WD: Larger font sizes will require us to reconfigure


AWK: Has the taskforce cleared any proposals where we can say "DONE" in
advance of Dec 1st deadline?


LC: I don't believe we've made any official final decisions


AWK: Good idea to target for next week?


WD: I should have Reflow done, with likely progress on Size of All Content


AWK: For next week we will look to start moving some to the "DONE" part of
the table
... Wayne, is the Reflow to Single Column the one you are working on?


WD: We need to reflow, which is basically a statement of 1.3.2
... I have read 1.3.2 very carefully, meaningful sequence, defined reading
order according to WCAG
... Moved 1.3.2 up to the criterion level, as well as the failure level
... With that, assistive technology to achieve reflow can be written


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



<Wayne> SC (Reflow Ability): The generated source order of the perceivable
elements of a document, at any point in the execution of a document,
defines a correct reading sequence of the document. If the author’s style
is removed from perceivable elements and replaced by styles preferred by
the user, that do not change the source order position of perceivable
elements, then the document is presented...


<Wayne> ...in a correct reading sequence.


AWK: confused about which is being covered, Reflow to Single Column or
other


WD: One of the critiques we got back from WCAG was that it was not specific
enough to indicated what the authors role would be in it, I think this
really is the structural responsibility of the author so that things can be
reflowed
... The way that it is stated in 1.3.2 technique, is that if changing style
changes meaning, it is a failure. This last part changes it, and says
removing tyle reveals a meaningful presentation, and if you add stuff that
does not change the order, it will not interfere
... There really were not any suggestions that made a lot of sense from an
industrial development process point of view, that supported anything but
maintaining correct reading order in your basic content, thus the
suggestion to move up to Reading Order
... You can step through list of elements in order and arrange in a single
column format


<Wayne> q


AC: Has noticed similarities with Reading Sequence in current WCAG.
Question would be about how different is it? Is it intended to beef that up
a bit? Can we do that in adding techniques? Is there something fundamental
missing from the SC? Agrees with the aim, but struggling to understand that
myself. Is it more about how people have interpreted Meaningful Sequence?


WD: It's basically saying that this is presented as a sufficient technique,
but it's really a necessary teqhnique. That is the difference in
interpretation


GS: Current 1.3.2 is going to allow the base reading order to not make
sense, or is that not true? Is what Wayne is suggesting required, that the
source code be in logical order


<ScottM> Reading Order = DOM order


WD: What 1.3.2 is that the order can be programmatically deteremined. I
don't see after reading the entire, everything to do with it, that there
are programmatically detectable ways to demonstrate the reading order.
Perhaps Tab Index. I don't see the existence of a programmtically
determinable way to communicate the authors intended sequence. It's the
authors meaning, so there's no way to get it without stating the exact
sequence. That is my issue[CUT]


<ScottM> 1.3.2 does not address making the reading order visually readable


AWK: I look at an inspection tool which shows me the DOM order within a
browser, or a PDF tool which shows order as expressed to API. The only
reason in Flash where we needed to say, was because this automatic player
Runtime made guesses about reading order based on crazy formula
... Questions using Tab Index all over the place


WD: I would not say that


AWK: Alastair asked what would fail this new one, that wouldn't fail the
old one


WD: I have a question about that: Are failed cases normative?


AWK: No


GS: They are more powerful than normative in my opinion


<Glenda> Could we add this as a failure?


AWK: If you were standing before a judge asking if it's a normative
failure, I would say no


WD: What I want to be able to do is step through DOM order in a document,
take style and put in our SC as user needs it. If outside browser, I cannot
interact with it. I would like to be able to write an extension in the
browser to be able to use it.


<Glenda> Could we add this as a documented failure for 1.3.2 (it would help
clarify the valid point that Wayne is making).


AC: it is tricky, because it tries to strengthen 1.3.2. If user removes the
styles to improve the order, trying to think of text about how that could
work, but struggling.
... Flexbox and Grid have ways of changing the order so that visual order
can be different than DOM order, but causing issues for keyboard access and
screen readers. Seems a good SC to be had here, but trying to push toward
the first part of the simplified wording.


<Zakim> alastairc, you wanted to ask whether we should look at possible
flexbox and grid CSS issues to make the case for this.


<AWK> +1 to Glenda's comment that this is already covered by 1.3.2


GS: Would be fine if we see strong evidence that it needs to be part of SC,
what if we documented a new failure, because while I know failures are not
normative, they are so close that they really have a lot of clout.


WD: I would be fine with a new fail. We do have the failure that if you
remove the style, and it changes the meaning, then it is a failure.


LC: New failures have been difficult to get through lately in the working
groups


<laura> New failures have been very difficult to move forward in WCAG WG.


SH: I think if we say something we consider to be new SC, instead we're
comfortable with having a new failure, we need to make clear what is
required for user to be satisfied. In this case we're saying a new failure
is essential for covering low vision user needs


AWK: This started out as Reflow to Single Column. This seems very clear,
but the new simplified wording, makes it sound just like 1.3.2. Is this SC
proposal actually accomplishing what we want?


WD: Here is the problem, whenever I have tried to have that something is
violating 1.3.2, people say I am over generalizing 1.3.2
... What would make me comfortable to have this, is that people would say
yes, in fact, we have this. There's no placing reading order any different
way. As long as you can reflow.
... There will be many who say, No, that's not what we meant.


<Glenda> Proposal: We try to add it as a Failure. If we fail (at making
this a documented failure for 1.3.2) then we could proposed a new SC.


WD: The problem with low vision is that we used to have this in Section
508. Now that it's WCAG, we don't have this anymore.


<Glenda> I like that wording, alastair.


AWK: I don't think 1.3.2 is different from the old


<ScottM> "The DOM order must reflect the reading order"


AC: Part of conversation last week was about a good maximum, but in Wayne's
scenario, still not enough, so the idea of the reading order is beyond the
400% maximum, it's about removing the layout.
... Trying to set up for a scenario of layout being removed, but not
necessarily the styling


<alastairc> I was thinking of wording like "When the elements of a page are
presented as a linear sequence they retain a correct reading order."


SM: Rather than saying they need to be functional without style sheets,
simply say the DOM must reflect the reading order. We encounter all the
time, things like simulated dialogs come up and are presented at the
beginning or end, but takes searching.


<alastairc> This would add to the case:
http://adrianroselli.com/2015/10/html-source-order-vs-css-display-order.html



SM: There are ways DOM order can screw up for reading order


<Glenda> Alastair, can you add the word “visual” in front of elements so it
reads like this: “When the visual elements of a page are presented as a
linear sequence they retain a correct reading order."


SM: The only way it will work with current technology, is say the DOM must
reflect the intended reading order. Will solve for low-vision and screen
reader users as well.


AWK: Number one reason failure proposals don't get accepted is when they
simply restate SC
... Wonders if people are misinterpreting 1.3.2 now


<Wayne> Meaningful Sequence: When the sequence in which content is
presented affects its meaning, a correct reading sequence can be
programmatically determined. (Level A)


AWK: If we are talking about SC, is so that it can be technology
independent


AC: Pop up dialogs are a good example, because they can still be generally
accessible regardless of position


<ScottM> screen readers and other AT doesn't support Z order so the entire
doc is still accessible to the user


AWK: If you have a dialog, and you put at the end of the order, but it's
proper and tested, it effectively becomes the entire DOM order right there,
you are accessing it, and not everything around it


SM: Problem is no AT I am aware of supports any layering of any sort. All
other content is still there, but if focus is not moved, user has to go
search for the dialog


AWK: That scenario layers on another


SM: Does not understand why we cannot just say DOM must reflect reading
order


WD: Did not want to get in to computer science of it, but my statement on
generated source order, I am literally saying at any point in the execution
of a document, that generated source order of those elements that the
author wants to be perceivable are in a reading order at all times


<AWK> That is exactly what 1.3.2 says


WD: Every single document language is defined by context free grammar,
There are certain non-terminals that behave just like elements in a markup
language.
... The point is, every language that is used to generate documents has
something that works like an element
... at time wcag was written, time was much less of a factor
... this is about elevating informative elements to normative


AC: We'll still struggle with distinguishing, not that i'm opposed
... still in favor of putting forward a SC like this, and using 1.3.2 as a
sort of fall-back
... Would rather not use references to generated source, and DOM, and HTML
specific things, but talk about it in terms of layout, and flow, and
sequence, and just make sure that it achieves what we want


AWK: Disagrees that it's not part of 1.3.2, still has some work to do
... Moving on. Thinking about general timeline that we've got. We have 6+
weeks before Dec 1st deadline. The first question is, does everyone have
one of these SC wiki pages that they are working on?
... We have 17 more, and will need to make progress


<Glenda> I don’t have one. who is working on what?


<Glenda> I”ll take it


AWK: Contrast Informational Graphics, Erich will take that one


<AWK> Erich:
https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Informational_Graphic_Contrast_(Minimum)


AWK: Contrast Interactive Graphics, has several comments from TPAC, Glenda
will take


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



AWK: Seeing All Interface Elements, Alastair believes this is covered and
proposes we drop


<AWK> Wayne:
https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Seeing_All_Interface_Elements



WD: I can take a look at it this week to check for overlap


AWK: Font Family, Alastair suggests working on this one with Wayne


AC: I am happy to start at the top and see how similar they look


<AWK> AWK and Alastair will look at Font Family, Line Length, and others
for possible grouping


WD: You can review element-by-element, don't need to have one choice for
the whole page


AWK: Printing Customized Text, Shawn unable to take primary on it, but
willing to help
... Can you do something about this as an author, or depends on doing the
right thing?


SH: When I'm putting content out, I put it out in a way that the users can
do this. Authors choose what format to provide the information in.


AWK: With no volunteers for primary, we will let that one sit for the week


SM: Will look and see which he can take a stab at


<Zakim> shawn, you wanted to ask 1. what it needs, 2. how it fits with
personalization


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



SH: For the printing one, what does it need?


AWK: It looks like testability, and partial related info


SH: Alastair, were you looking at personalization and how it fits together?


AC: I was going to take a first pass at font family with others and see how
they compare


SH: This one fits in to the whole personalization


WD: Maybe putting off printing for a week is not a bad idea if we look at
these other things


AWK: We won't get to them all in a week anyway


WD: Maybe we could change the name to Local Level Customization


AWK: Using User Settings, the last one, seems to be the most undone one
that we have


SH: Did we say previously this one might not be needed?


WD: Let's think about whether it's outside of the authors scope at this
time


SH: I will check the minutes, and see if we might be able to cross it off
our list


AWK: I would like if people could send me their updates about where they
are at, and their conclusion, by the end of Tuesday (10/18), so that I can
get this out prior to our call on Thursday


WD: Is there a way that we could get access to the WebEx somehow so that I
could talk face-to-face with Alastair about this?


SH: Happy to set up WebEx if that's helpful


<shawn>
https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Using_User_Settings#Minutes



SH: Has found the minutes, and added them


<AWK> Add review of minutes for whether to drop Using User Settings or not


<laura> bye


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




50443283.jpg
(image/jpeg attachment: 50443283.jpg)

50047443.jpg
(image/jpeg attachment: 50047443.jpg)

ecblank.gif
(image/gif attachment: ecblank.gif)

50608040.gif
(image/gif attachment: 50608040.gif)

Received on Thursday, 13 October 2016 16:34:59 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 27 April 2017 14:44:31 UTC