- 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