See also: IRC log
<AWK> +AWK
<AWK> Chair: Joshue
<AWK> Scribe: Wayne
<AWK> https://github.com/w3c/wcag21/wiki
<Joshue108> https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria
<Joshue108> https://github.com/w3c/wcag21/wiki/Tending-to-SC-Proposals
<alastairc> scribe: alastairc
AWK: Notes the instructions for current SC managers who are tending to the issues: https://github.com/w3c/wcag21/wiki/Tending-to-SC-Proposals
<Joshue108> https://github.com/w3c/wcag21/wiki/Tending-to-SC-Proposals
Joshue108: Just a reminder to try and update your SCs please. And read through to the end, there are a few little things that can catch people out.
AWK: Please drop us a note when you've updated it.
Wilco: 2 weeks ago we sent in the framework for review. We've had a couple of comments, we've addressed those. No major issues.
<AWK> https://www.w3.org/2002/09/wbs/93339/ACTFrameworkFPWD/results
Wilco: We did decide to change
the name on the document, so it is now ACT Rules Formats.
Changed to remove confusion with term 'framework'.
... this is a format, so we went with 'format' for the new
name. Apart from that we think it's ready for 1st draft, just
need approval form the WG.
Lisa_Seeman: Wondering if there's
a proposal to also formulate to test against a baseline of
technologies. People are asking for testing in 10 different
places, how to manage where you should manage for the human
side of testing?
... e.g. a way of helping people to define what is a good way
of testing with particular user agents, NVDA & JAWs in 2
browsers etc. How do we quantify this?
Wilco: We don't directly address that, I would suggest organisations have to decide their baseline for their scenario. What we do consider is taking accessibility support information into the testing processs. E.g. define the features required, and then work out if those features are available in the ATs.
Joshue108: We'll have a CFC going out soon, please reply when you see it.
<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_timeline
Joshue108: A little update whilst
we work on this. We have comments open until the end of
March.
... we're looking at publishing 5 working drafts over the next
few months, then tools down at August 22nd. Then after TPAC
(Nov) we'll have a wider review document before the new
year.
<Zakim> AWK, you wanted to say that August 22 doesn't mean no further changes but no further additions
AWK: August 22 doesn't mean no
further changes but no further additions, we'll be looking at
refining things after that point.
... all the dates are on that wiki page: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_timeline
jamesn: One Working Draft a month, how will we address the comments between them? It seems strange.
AWK: Some groups are updating the drafts regularly, weekly or daily even. We're going a lot slower than that.
MichaelC: We may not be explicit about addressing comments until the later phases, and we can use the change-log to highlight changes.
jamesn: It's the feasibility, we'll have a ton of comments coming in, how do we address them on that schedule?
AWK: Need the WG to be
comfortable with a couple of things - getting used to coming to
consensus on new SCs. There being automatic turning the editors
draft into the working draft, that will be what goes out.
... Then comments will be coming in, if we can't address it
that month, we'll have the change log, they can see what has
changed (or not). We'll also need to indicate when comments are
done and addressed.
... in github.
Lisa_Seeman: I've been asking to bring back the TF co-ordination meeting for things like this. I've assumed we'll have a year to get things to a certain level, but now it is 5 months? E.g. getting people to buy in AT. Plus we haven't worked out a process to get the thornier SCs through, how to we build the consensus? That isn't in place, we need to work on the process of finding solutions and resolving issues first. What are the priorities in terms of
balancing the user vs backwards compatibility.
Joshue108: We've had a fairly clear timeline for 2.1, that shouldn't be a surprise. We've 3 task forces, and we're still planning to have the spec ready for June 2018. 2.1 will be within the 2.0 framework, so those parameters aren't changing much.
MichaelC: On throughput of comments, only things which get into 2.1 will be ready, there is still 2.2 at a later date. We are not going to cram un-reviewed things into it. Balancing the previous comments.
Lisa_Seeman: There's a big difference between stopping putting in new SC in Aug vs Dec, that's a shock. It's a high impact decision.
Joshue108: If there are SCs that need more time, the WG can consider that, especially if there are good reasons for it taking more time. But, it is not pushing the schedule ahead, we're just drawing a line between drafting and refining, what goes into the final CR.
<Zakim> AWK, you wanted to talk about the importance of making the timeline and whether all proposed SC will make it
<Lisa_Seeman> Absolutely shocked
AWK: To underscore, WCAG 2.1
needs to get out on the charter timeline. We have had a great
deal of scrutiny on this point, it was the largest sticking
point. If we have to put out CR in Jan 2018, we have to stop
putting in new stuff and refine what goes in there. That is v.
important.
... There are challenges, and we shouldn't count the number
going it to 2.1 yet. No one is saying the new SCs are bad
ideas, but there are many challenges to new SCs. Deciding the
schedule is a WG decision, changing is also a WG decision. We
are not serving our users or our sanity to keep adding things
in at the last minute.
... this is all part of the schedule in the charter.
Lisa_Seeman: I think this needs a TF call with the TF chairs, there are other ways we can address the deadline issues. I don't agree with this.
<Zakim> AWK, you wanted to say that the timeline isn't a TF coordination issue
<Glenda> my mantra is…2.1, 2.2, 2.3. All will be well.
<JF> +1 to AWK - the timeline is a Working Group discussion and decision
AWK: The timeline isn't a TF call issue, we can have that call, but it isn't a TF co-ord issue. How we work within the TFs, that is. The WG is the body that decides on timeline. Three questions: comments on timeline, whether people agree with additions to Ed Draft to go through CFC, and whether we're confortable for those drafts to be published now for the upcoming drafts.
<jeanne> +1 Glenda
Glenda: Have no problems with the proposed timeline, as 2.1 isn't the end. Could go to 2.2 / silver.
<Makoto> +1 to Glenda
Joshue108: Urge everyone to consider the bigger picture of publishing WCAG 2.1
Lisa_Seeman: With August (no further SCs), the change (today) of cut-off date, people aren't going to see them all.
AWK: That may be true, it is not specifically for COGA, we've got a lot in and most have received a review. It isn't fair to say they won't get looked at, perhaps if they were looked at more it might help, but we do have a timeline to keep to. There has to be a cut off point.
Joshue108: These dates come from consideration of W3C process and experience of people doing this before. If there are SCs that fit into WCAG 2.0 framework more easily, front-load those in the queu.
<Lisa_Seeman> this august date has just been thown at us. no discusion before
David-MacDonald: I was one of the people who wanted a longer timeline, but the group spoke, and I've learned over the years that when we make a decision, I go with it. I think August is reasonable for the deadline we have.
AWK: Just want to make sure we get from the group, are there concerns about our 'automatic' generation of the working drafts from the editors draft? Propose a CFC.
I had assumed we would do that anyway...
Joshue108: One of the SCs close to consensus was User Interface Component Contrast, would like to start there.
<Joshue108> https://github.com/w3c/wcag21/issues/10
Joshue108: Had you updated it Glenda? What come out.
Glenda: Great feedback last week, working with the suggestions, updated the text. Removed 'thereof'. Tried to add a definition.
Joshue108: Pretty close to being ready? Can people please have a look at the updated SC and let us know if you can live with it.
David-MacDonald: Would it be better to have just one ratio for all graphical objects? Is the higher ratio needed for objects compared to text?
<Glenda> Failure examples http://glendathegood.com/a11y/lvtf/submitbuttonbordernota11y.html
Glenda: we don't have consensus
on that yet, would be good for the group to look at those.
These demo borders show items with under-contrasting
graphics.
... Without having low-vision it is hard for me to say. Can any
one chime in?
<jon_avila> I would be fine with 3:1 for borders -- just personal opinion
Wayne: I could look through it, I really have a hard time finding focus indicators. I'll look at it. Previously we made a mistake with 3:1 previously.
<jon_avila> for focus indicators I would want 4.5:1
AWK: In the examples (very helpful), it is borders, but what about other examples? E.g. it has a pencil graphic inside that has good contrast?
Glenda: Then we get down to
'essential', is that the visual indicator? If that meets
contrast is it enough?
... Had a question about combo-boxes without borders, but there
are little visual indicators, so those would pass.
AWK: depends what graphical object is defined as?
alastairc: My go at graphical object: https://alastairc.ac/2017/03/graphics-contrast/#graphical-object
<David-MacDonald> This is what I would suggest to simplify "The visual presentation of all essential graphical objects for user interface components has a contrast ratio of at least 3:1 against the immediate surrounding color(s), it is disabled or otherwise inactive user interface components are exempt from this requirement."
Glenda: A keyboard focus indicator is covered, but what makes that a keyboard focus is flexible.
<AWK> Information in graphical objects used for user interface components which is essential for comprehension has a contrast ratio of ...
Joshue108: If someone wants a visual focus indicator, is that covered?
<Zakim> Joshue, you wanted to say I'd rather push for the highest possible
<Zakim> Greg, you wanted to say the "Thicker" list item needs to say "at least" rather than an absolute ratio
<David-MacDonald> oops >The visual presentation of all essential graphical objects for user interface components has a contrast ratio of at least 3:1 against the immediate surrounding color(s), unless it is disabled or otherwise inactive.
Glenda: This one covered interface components and focus indicator.
Greg: Have a problem with a figure thing
<Greg> The phrase “or (one of) their border line(s)” is potentially problematic: if a rectangle is drawn with only one side being thick, the 3:1 would apply to the entire border, including the thin lines, and that does not seem to meet the goal.
Greg: it needs to say 'at least' rather than an absolute ratio. also, what about having a rectangle where the border isn't uniform.
<Greg> "A contrast ratio of *at least* 3:1 is required where either the graphical object or *its border has* a minimum width and height of at least 3 CSS pixels."
<Glenda> Proposal…we drop back to 3 to 1 and loose thicker
Glenda: And all of this is moot if we move to 3:1 only.
<Kathy_> What about multi colored essential graphics.
Greg: yep, keep that around if that exception comes back.
Glenda: Will change the 'at
least'. The partial borderline what me being minimalist, trying
not to dictate design, and overlaps with essential.
... we need to step back and keep it minimal.
<Lisa_Seeman> +1 to josh
Joshue108: Is minimal being under-specifying? Would rather start stronger then step back from it.
<Joshue108> +1 to having one measurement that was strong.
<Joshue108> -1 to the 3 pixels thing - I don't know how people would measure that.
marcjohlic: would we keep the thicker? If we go to 3:1 we lose that exception, sounds like this is covered, like having just one ratio. Although, what if the example with the down-triangle is very small?
Wayne: Two things: when a person
is looking at a page, they have to determine that it is a
control, then understand it. With just text without a border
you couldn't tell, with a clear icon that would be
understandable.
... there is a cognitive process involved.
<kirkwood> agreed
<Zakim> AWK, you wanted to ask Greg if he feels that a control must have a border all the way around
<AWK> https://goo.gl/forms/Af0E6ElBFKPaAWGe2
AWK: Does the border need to go all the way around? I'd say this should fail in initial view, it has one very light line. If the focus style was there it might be ok?
Greg: I'd say a border is
required all the way around depends on usage. I can probably
find examples, e.g. a list of words which are actually buttons,
a line appears between them, and you can't tell if it is the
word either side.
... in this case, having the thick underline underneath is
probably sufficient.
<Wayne> What if we devised a test with a page that embeds controls in more or less obvious ways and ask out LV members to find and evaluate the controls.
AWK: In which case we wouldn't require it for all the way around?
<Glenda> Greg, I think we are dancing near the line of poor design / bad usability for all.
<jon_avila> standard controls can be modified with CSS
<AWK> +1 Jon Avila
Greg: I agree that would be a problem, we'd be requiring that. In cases where the built in things fails, we'd be failing everything on certain browsers. Another approach would be to apply it to custom controls. So default controls work, but if you customise them then you need to meet the contrast requirements.
<Greg> Thus, I would recommend that this type of SC only apply to custom or customized controls.
<Zakim> jnurthen, you wanted to say I strongly disagree with not allowing the default focus indicator - I much prefer my chrome focus indicator to site-specific ones. I don't want that to
<jon_avila> Bad design affect people with disabilities differently
<kirkwood> agree with James on focus indicator through browser
<kirkwood> +1 to james
<jon_avila> Some authors hide the focus indicator with outline:none
jnurthen: I don't like it
preventing my default indicator, would rather not have it fail.
It's a fail of the browser, not the content.
... outline none is a fail, agree.
<marcjohlic> +1 to jamesn - should only apply when dev uses a custom focus indicator. Using default UA focus indicator should be allowed.
<kirkwood> Browser focus indicators through user agent are very good for COGA
<jon_avila> Some people use only background colors changes to indicator focus -- background goes away in high contrast. But high contrast mode seems to put focus indicator back even if outline: none was set.
<Glenda> How do I raise this to the User Agents? UAAG?
Joshue108: This is one that is due to poor UA implementation, but I hear there is still a requirement for contrast.
David-MacDonald: I'm not sure this language requires us to have sufficient contrast on focus indicators. do we want that?
<Glenda> see proposed definition…y’all made me take out the reference to visual focus indicators (out of the SC)…based on last week. (sad face)
<jnurthen> but you would fail the "color alone" standard
<Joshue108> Glenda, could you speak about that nextt?
David-MacDonald: there is the contrast between the interface components, and their background, then the focus indicator and the background elements.
<David-MacDonald> The visual presentation of all essential graphical objects for user interface components and their focus indicators, has a contrast ratio of at least 3:1 against the immediate surrounding color(s), unless it is disabled or otherwise inactive.
<Zakim> steverep, you wanted to comment on focus indicators
Steverep: Wanted to comment on focus indicators form LV point of view. The default indicators on several browsers would fail, there is a reason AT changes that. The AT options I have are things like frames, blocks of colour, underline and more.
<kirkwood> Steve, the focus indicators “indeed fail”? If that is true then my comment is not correct.
Steverep: Difference between focus indicator and meeting it in all states of the page, whether it's in focus or not. I view it as, if you change a button it still needs to meet colour contrast.
<Wayne> +1 all browsers fail
<laura> Some people with low vision don’t use AT.
Glenda: The entire time the SC
had three separate things, which was taken out last week, and
it has caused more confusion. There should be no question that
it applies.
... will put it back.
<kirkwood> +1 to Marc
marcjohlic: Is there room to say that it applies once you've messed with the focus indidator? Then put the default off to Silver. Big issue to tell people they have to style it when they have relied on the default.
<steverep> Could we just say "in all states of the page" or imply it another way?
Joshue108: Does bring up that question, if you need higher contrast. If that can be done in the AT...
Glenda: It is so confusing to
deal with user-agents doing it wrong, and say that's ok, but
then say the developers have to do it right. I don't think the
burden is that great.
... The oreo method allows you to do it ones in your CSS.
<jon_avila> We need a minimum level of support without having to apply AT or extensions to every website.
Wayne: You assume people use AT, many of us think the approved AT (magnifiers) is bogus, I've proved it costs people 40 times the work. It was very difficult based on WCAG 2.0.
<laura> +1 to wayne
Joshue108: We're trying to improve things, it does impact the SCs. Not intention
<Wayne> +1 on familiariy
<kirkwood> agree that being different focus indicator on every site will increase cognitive load and therefore less accessible
jnurthen: Ideal would be if the browsers met the contrast requirement, that's the end game. If we get every website to do it, they will do it differently, that will make things harder. You'd make it unfamiliar. you can do that in firefox, Chrome's is ok, could be better. that has to be the way to go.
<marcjohlic> +1
<shwetank> +1
<Zakim> Greg, you wanted to point out that UAAG 2.0 defines and uses a number of terms relating to focus indication, which we should use if and where we discuss those concepts.
<kirkwood> +1 to James
<marcjohlic> +1 to Greg
Greg: UAAG defines terms related to focus and indicators, please reference.
+1
<laura> +1
<David-MacDonald> + to the amended 1 contrast ratio one
<AWK> +.75
<Wayne> +1
<Glenda> +1
<Joshue108> +1
<JF> +1
<Mike_Elledge> +1
<MelanieP> +1
<KimD> +1 to "going the right direction" but -1 because we don't have the final yet
<Makoto> +1
<Greg> I'd like to see the updated wording before voting on it.
<Glenda> (I’m out of town on Thursday…I won’t be able to make the Thursday meeting)
<marcjohlic> +1 going in right direction (one 3:1 min) - but would rather not force change of default indicator reqs - follow uaag - and if you customize it then this applies
<Jan> +1 to seeing the updated wording
<KimD> +1 to revisiting
<shwetank> +1 to revisting
RESOLUTION: Leave open, with final contrast ratio to be determined next week.
Lisa_Seeman: This is where we needed a process that doesn't take up as much time as this. Perhaps we can use the thursday call to resolve it.
Joshue108: We need to discuss topics for thursday on email.
<laura> Bye all.
trackbot, end meeting
<Mike_Elledge> bye
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/Joshua108/Joshue108/ Succeeded: s/sliver/silver/ Default Present: AWK, Kathy, Greg_Lowney, shwetank, alastairc, Lisa, Melanie_Philipp, adam_lund, Joshue108, MichaelC, Makoto, Laura, marcjohlic, Mike, Elledge, Glenda, Wilco, kirkwood, Wayne, jeanne, Jan, jnurthen, jon_avila, steverep, KimD, .75 WARNING: Replacing previous Present list. (Old list: (no, one)) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK WARNING: Replacing previous Present list. (Old list: AWK, Kathy, Greg_Lowney, shwetank, alastairc, Lisa, Melanie_Philipp, adam_lund, Joshue108, MichaelC, Makoto, Laura, marcjohlic, Mike, Elledge, Glenda, Wilco, kirkwood, Wayne, jeanne, Jan, jnurthen, jon_avila, steverep, KimD) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, Kathy, Greg_Lowney, shwetank, alastairc, Lisa, Melanie_Philipp, adam_lund, Joshue108, MichaelC, Makoto, Laura, marcjohlic, Mike, Elledge, Glenda, Wilco, kirkwood Present: AWK Kathy Greg_Lowney shwetank alastairc Lisa Melanie_Philipp adam_lund Joshue108 MichaelC Makoto Laura marcjohlic Mike Elledge Glenda Wilco kirkwood Regrets: EA_Draffan Jim_Smith Bruce_Bailey Denis_Boudreau Mike_Pluke Mark_Hakkinen lauriat Pietro Found Scribe: Wayne Inferring ScribeNick: Wayne Found Scribe: alastairc Inferring ScribeNick: alastairc Scribes: Wayne, alastairc ScribeNicks: Wayne, alastairc Found Date: 28 Mar 2017 Guessing minutes URL: http://www.w3.org/2017/03/28-ag-minutes.html People with action items:[End of scribe.perl diagnostic output]