- 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.c>
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.
Attachments
- image/jpeg attachment: 50443283.jpg
- image/jpeg attachment: 50047443.jpg
- image/gif attachment: ecblank.gif
- image/gif attachment: 50608040.gif
Received on Thursday, 13 October 2016 16:34:59 UTC