Low Vision Accessibility Task Force Teleconference

13 Oct 2016

See also: IRC log


Alastair, AWK, Shawn, Glenda, ErichM, Laura, alastairc, ScottM, Wayne



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


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

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2016/10/13 16:27:45 $

Scribe.perl diagnostic output

[Delete this section before finalizing the 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
Default Present: Alastair, AWK, Shawn, Glenda, ErichM, Laura, alastairc, ScottM, Wayne

WARNING: Replacing previous Present list. (Old list: Wayne, Shawn, ScottM, Alastair, Glenda, ErichM, Laura, 1, AWK, Erich_Manser)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Alastair, AWK, Shawn, Glenda, ErichM

Present: Alastair AWK Shawn Glenda ErichM Laura alastairc ScottM Wayne
Found Date: 13 Oct 2016
Guessing minutes URL: http://www.w3.org/2016/10/13-lvtf-minutes.html
People with action items: 

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

[End of scribe.perl diagnostic output]