Accessibility Guidelines Working Group Teleconference -- 14 Nov 2017

<Joshue108> trackbot, start meeting

<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 14 November 2017

<Mike_Elledge> I will scribe for an hour.

<KimD> *Is anyone having problems with WebEx?

<Mike_Elledge> scribe: Mike_Elledge

awk: We will assign scribes as we go along

<shadi__> presnet+

Schedule for the week

<lisa> webex link not working

jo: First issue realting to schedule. Have an extra call next week and potentially forward.

<lisa> ah, i see my mistake

<AWK> Wednesday, November 15: 2-4 Eastern time

JO: Nov 15 potential call date.

<AWK> Thursday, November 16: 11:30-1 Eastern time (reclaiming the 30 minutes)

<AWK> Friday, November 17: 11-1 Eastern time, 3-5pm Eastern time

<AWK> Need to decide on which time on Friday

<lisa> i can not make friday\

JO: Can people make those calls? Wednesday @ 2PM and Friday @ 11AM

<Rachael> I can call in only on Thursday. I can make both Friday meetings.

JO: Friday at 11AM or 3PM is the question.

<Detlev> 11

<lisa> i can not make iether

<Glenda> either works

11, but not certain I can attend.

<Brooks> 11 works for me

<steverep> 3pm

<Alex> 3pm

<jamesn> 3 is possible, 11 is not

<JF> it would be helpful to have an idea of agendas for those days

<JakeAbma> 11 for me

<Joshue108> 11 for me

<AWK> and resolving comments

JO: 11 it is.

AWK: Will have to add meetings if we can't otherwise get through comments, or do additional working draft. Otherwise may ahve to change schedule or expectations for 2.1.

lisa: Can we make it easy to know what will be discussed in meetings? Otherwise hard to know which to attend.

<jamesn> +1 to Lisa - also after TPAC many of us have a lot of other work to catch up on.

jo: Keep an eye on the agendas. Best way to know. Trudging through items. Keep an eye on what's coming up on list.

lisa: Can you make agendas as clear as possible. Zoom, etc. So easy to see what's in email.

<alastairc> There are plenty of us, if we all make 2 / week that should be fine. (They will go to CFC afterwards anyway.)

jo: Zoom, contrast today. Hopefully will go through them. Appreciate it's tough to know. Makes it more difficult with surveys--want everyone to have time to respond.

awk: next items in survey: device sensors, orientation and #251. Three more when we have call on Thurs will approve those.
... We've been doing a lot of review recently. Need to be efficient and resolve add'l comments. Identify compromise positions.
... Keep that in mind; what can accept or not.

jo: We'll keep things expedited as best we can. Thx for patience and energy.

CFC for Character Key shortcuts

Zoom Content: https://www.w3.org/2002/09/wbs/35422/ZoomContent_20171109/results

jo: This has changes from TPAC. Reflow. 11 agreeing. one comment: minor concern with changes. Major concern Steve R.

Steve R: in short does not reasonable, just single working item. Defeats low vision. Edit to stick within widths of 322 or greater.

<alastairc> For MikeE: 2D layout means that it is intrinsically 2D (like and image, video, data-tables). Means they are exempt, not that they require scrolling necessarily.

<Detlev> I didn't understand the suggested change

James: How can we test that. Every single point. Not possible. I understand what we're saying. Maybe take intermediate points for testing.

Steve R: Can appreciate that. What is a testable range? Then can calculate factor for widths.

<alastairc> Theoretically it should be at whatever points the site defines as breakpoints, but no idea how to integrate that into SC text.

James: Is it testable at 960? Happy to test add'l widths so long as no other issues. How do we test if something has to be 1080?

<Zakim> AWK, you wanted to say that the problem with what Steve is proposing increases the testing burden substantially. And needs an upper bound.

awk: Am in line with what James is saying. Also note that Steve requires an infinite range ("or larger").
... Don't want to test at higher sizes so fills entire page.

<Glenda> @Steve, can you live with two test points. 1 at 320px and 1 at 1280px.

steve: no one designing that big. So stops mattering at some point. Who's designing for 3000 px wide.
... Would expect of designer, but not tester.

awk: That's the issue. Requiring the tester. Part of the challenge is that when ppl using responsivle design...at different intermediate sizes things happen.
... Why we went to flow.

DM: next!

jo: What can we do now to iterate this SC? What would make this do particular job well? Steve, do you see current text as step in right dirction that can be revised.

Steve: Can't live with a single test point.

<Detlev> 320 and 640

Glenda: Can you live with two as step in right direction? 1280?
... if we can move you to two test points will it work?
... 320 and 640.

<alastairc> Knowing what points they are? Theoretically they should be different on every site anyway.

Steve: Think we need more than two. Where's the burden of add'l points. Going from 0 to 2 test points. Don't ask for too much now.

jo: Seems like ppl could live with a couple of points.
... What would you suggest Steve?

<alastairc> We know that *most* sites will do it in a responsive manner anyway, so having one test point is not that big a problem.

<AWK> other mobile pixel widths of note: 640, 720, 768

<Glenda> @Steve, I fear if you do not pick 2 points to test, this SC may not make WCAG 2.1.

<Glenda> @Steve, are you willing to let this SC wait until WCAG 2.2 or SIlver?

Steve: <long pause> Having a tough time with this. calling it reflow but doesn't require reflow. LV ppl make things bigger. After that want to prevent scrolling back and forth. ON zoom curve, one is not enough. Three enough? Get diminishing returns. Right now have 4x zoom. Need something that's enough to require reflow.

<jamesn> 2x, 3x and 4x (640, 426, 320)

jo: Time is of the essence. Please think about it. Need to set so ppl will do.

<JakeAbma> maybe solution to add 3/4/5 but for testing 2 will be enough, covering all the others and not asking for more time to test

<Detlev> +1 for jamesn (if it must be more than 2)

<alastairc> I would have a problem with picking a standardised set of points between 320 & 1280, as they undermines the whole responsive design approach. It would have to be tested at the breakpoints the site defines.

md: Group getting together Wednesday?

<Joshue108> +1 to Alastairc

james: Content may not zoom to 4x at 322.

<AWK> Sometimes when you zoom in or decrease the window width the text gets smaller

<Zakim> AWK, you wanted to say that we can't guarantee that people won't find a loophole, but is it likely or advantageous for the developer who is looking to support a mobile audience?

dm: Don't say content is zoomed at proportional rate. Don't have problem reconciling Steve's issue. At 400% seems to solve it.

<Glenda> @alastairc could it be test at an defined breakpoints. If no breakpoints defined, test at X and Y. (Where we establish 2 widths to test at…as a better than nothing)

awk: With these SC trying to set conditions for likely success. Can't guarantee at 3 points that someone will test for reflow. Testable, encourage, but can't guarantee every scenario.

<Detlev> I think the *SC* has to set the points, getting this from author CSS breakpoints seems impractical

awk: How like will designers will go out of their way to meet this SC at this one level.

Steve: WRT David's comment. On board with separating reflow and making things bigger. Doesn't nec effect ppl with LV. May not be zooming to get larger heading.

<Glenda> @Detlev, what if we all had a simple tool that quickly told you what the breakpoints are for the page you are on? (Like a new info option in Web Developer toolbar)?

Steve: Key part is reflow to eliminate scrolling. Yes, wrt awk, if you leave open door ppl will walk through it.

<Zakim> bruce_bailey, you wanted to suggest title change

jo: Also assume ppl will do what's right. So have to support criteria that will facilitate that.

<Detlev> @Glenda whether you hit the breakpoint exactly does not matter - uses us all sorts of widths so any 2 or 3 points should do th etrick

bb: Is the issue with the title? At 320 will work at 3 magnification. Supporting reflow is aspirational. Saying 320/640, really three designs. Designer will have default size and add sizes to support SC.
... Could live with two.

jo: How about call it as it is? Say this is for small screen sizes to make it work. Are we throwing out other things that SC could address?
... Changing it to small screen might be an option.

Steve: Doesn't address user need which is Reflow.

jo: Unless we have two SC.

Steve: Assuming that can get to 320 px on desktop other than reducing viewport to 320.

<Zakim> gowerm, you wanted to say that small screen is not the primary objective; ability to zoom without scrollbars was

<Detlev> @steverep all major desktop browsers support page zoom so what scenario are you referring to?

mike g: Would be concerned about this being only small screen view. Idea to eliminate horizontal scrolling. If not being done should reconsider title.

Steve: Some way to build reflow into it?

jo: Alistair's point about size of device. I'm concerned being too prescriptive. We should be independent of values unless they're bullet-proof.

<Zakim> jallan, you wanted to say not about small screens, but getting small screen view on a large monitor

Jallan: Want a mobile view, one column, everything wraps. Except maybe tables, images that don't fit. May have lost that notion.

<AWK> So Jim, does the proposed SC text from the survey address most of what was intended?

Jalla: Understand S's point of 320, designers not necessarily weasels, if design just to 320 site will break at other sizes. Most ppl want to do right thing. Happy to wordsmith.

jo: let's wrap. Thanks Steve for input, important and have clear vision. Further work on this, and come up with testable, not prescriptive language.
... Steve, come up with language you could live with? We're not there yet.

md: Don't have the time. how many days before next draft is due.

jo: Have to make sure that it's right, though.

awk: Don't have enough tiem to do everything. If issue is that something isn't perfect, can still change w/ add'l comments. Is it actively wrong, not going in right direction, or providing benefits.

<steverep> Add something around 800 and 500 and I'll stand down

<bruce_bailey> @Steve, do you want in as-is for 2.1 or wait for 2.2?

<Detlev> strong +1 for what AWK is saying now

awk: Could discuss infinitely. Woudl like curren proposed text to go in, given soem consensus, Steve ahs concerns, DM as well, but need to figure out whether it's a benefit or wrong.
... My gut is that it's a benefit.

jo: Heard what Steve is saying, don't want him to feel that not considered. OTOH lots of ppl have agreed.

<Glenda> https://deviceatlas.com/blog/most-used-smartphone-screen-resolutions-in-2017

jo: Adding something arbitrary has me concerend. How important to add one or two numbers. Are you confident that they are correct?

<Glenda> 720x1280 is the most used smartphone screen resolution

Steve: Yes, it's a constant factor. Start at 1280, go down 1.5 to 800, then 1.5 to 500, then 1.5 to 400%. Not arbitrary.

jo: Is having values at set points.

<Glenda> I’m fine with 320, 500 and 800

James: Having three harder to test than one, but better than infinite number.

jo: Maybe three points is the way to go.

<jallan> +1 to AWK. after rereading and thinking. Not horribly wrong. need to get this in. Will be good benefit

<Detlev> suggest to take the multiples suggested by jamesn

jo: Anyone have problem with doing 3?

<gowerm> +1 Glenda!

james: Liklihood that someone will go straight to 320. Hard pressed for anyone to do that. Will break designs. You will have a reflow experience in 90% of cases.

<bruce_bailey> I would rather us have 320 and 640 rather than 320, 500, and 800

<Detlev> 320, 500 and 800 equally OK

<alastairc> Big +1 to alex, I would be saying this to...

<bruce_bailey> 500 might be a good size for testing, but screen never were that size

james: Try to test to avoid the fringe cases. Cost benefit doesn't seem to measure up. Because testing applying to everyone. PPl tyring to weasel is rare. So trying to cactch them is disproportional cost to ones who won't

<Glenda> 320 640

jo: Maybe on other point. How about 640.

<gowerm> You are going to have to test Resize at each stage too

Steve: A lot fo that argument is probably correct, but saying easy to test makes it moot.

james: Adding to time and cost is tangible, just to catch weasels.

<Glenda> I recommend 320 and 640. If we find in WCAG 2.1 that we need more checkpoints, we add that later.

<alastairc> Plus the 200% text SC is also still there, with both it is harder to weasel out

<Glenda> +1 to what Alastair said: “Plus the 200% text SC is also still there, with both it is harder to weasel out”

james: to satisfy this requirement is not to break design bec screen sizes change.

jo: How about 320 and 640.

James: Don't think it adds anythign but cots.

<alastairc> Not connected yet...

jo: Awk, what do you think? Accept one extra point? should we make call on that? Some positive benefit.

<Glenda> there will be a huge positive benefit (with 320 and 640).

<alastairc> I'm in

<david-macdonald> I would prefer just one point

<Glenda> a third point would be “better” but the ROI is not high at all

awk: I don't know. Interested in hearing if other people on call prefer one or two points. I hear A saying there's not benefit. Steve wants more. Not sure where group is at.

<Detlev> Agree with Alastair - given the 200% SC remains one point should really be enough

Alastair: Basically with alex. Can't see why ppl would want to weasel. Asking for 200% text size as well as to 320 without horizontal scrolling. Would really have to try to get out of it. Would be a big improvement.

jf: A lot more aligned with you.

<david-macdonald> +1 to close the issue and move forward with one point

jo: Alastair put it well. Anyone meeting 320 would design to higher values as well. Do we keep at 320 or add 640? Steve could live with 640.

<Alex> no 640

<Rachael> scribe: Rachael

<scribe> scribe: Rachael

David: Sitck wiht one point.

<alastairc> I would rather not, could live with 640 but seems pointless.

<AWK> Agree with Alastair

<alastairc> Is this something we can test in implementation phase?

JOC: I would rather seethe SC go through as is, without the 640. Its possibly creating extra work. The single 320 point focuses attention on the very small screen. Then we can use understanding docs to explain the range.

<Glenda> +1 stick with SC as is (and test during implementation phase)

My preference is to stick with SC as is.

JF: Can you live with it as is Steve?

<gowerm> One point to make is that Resize does not disallow scrollbars. So in the weasel scenario Steve is envisioning, one could create a 320px version wihtout scrollbars, and then Resize to 200% with scrollbars

<Makoto> +1 stick with SC as is

Steve: I woudl object but we can move on for this call.

+1 to accept SC as is.

<Mike_Elledge> accept as is.

<david-macdonald> +1

<JakeAbma> +1

<bruce_bailey> +1 to keep SC as is

<Alex> +1 as is

<jamesn> +1

<kirkwood> +1 as is

<alastairc> +1

<gowerm> +1

<jallan> +1

<Glenda> +1 SC as is

<AWK> +1 to accept as it is

<Detlev> +1

<JF> +1

<laura> +1

<bruce_bailey> Are we changing the SC name?

<Joshue> +1 to accept as is

<Joshue> no

Steve: I'm concerned lots of low vision users are not zooming to maximum level. Maybe 150, maybe 200. That space is usually not designed for, particularly without scrolling. Even people designing for tablets won't design to avoid scrolling.

<alastairc> Steve: I understand that, but putting one stake in the ground means people have to think about it, and when they do, they go responsive.

JOC: We can highlight the evils of scrolling in supporting materials. In terms of the SC, I see the group is accepting this as is with one objection.

RESOLUTION: SC criteria accepted as is, with 1 objection

<laura> We are losing the scrolling bit. Wayne would be disappointed.

CFC for Character Key shortcuts

Graphics Contrast and UI Component Contrast: https://www.w3.org/2002/09/wbs/35422/Graphics_and_UI_Contrast20171109/results

<alastairc> Looks like Steve's 2nd & 3rd comments need a little more work, someone could take that away.

Responses to comments https://www.w3.org/2002/09/wbs/35422/ZoomContent_20171109/results

AWK: There were comments but they roll up into implementation testing.

Steve: Were they addressed?

<alastairc> Note: If we hit issues, the fall back was to scope it to markup languages. But didn't want to say that yet.

I'm concerned with closing issues we haven't addressed. Is there a need to close it right now?

AWK: We do need to close issues. We aren't saying we shouldn't do it.

Steve: I don't want to close it and not note it somewhere.

AWK: Can we close an add these to notes for implementatoin testing to remind us?

We can also add references to the issues.

That would only leave 335 about reflow, how we've changed the structure of the SC.

Is the concern that you do not like the direction of the new SC?

<Zakim> gowerm, you wanted to say we need a clear process to capture outstanding items

Steve: We should notify the commenter where we move the data.

gowerm: I agree. We need a clear process for issues that are flagged in a comment that is closed. Otherwise they risk getting dropped.

<Joshue> +1 to implementation followup

AWK: We could add a label "Implementation Follow-up" Then we are easily able to search them all

<Glenda> +1 to idea from gowerm to add label to “implementation-followup”

Joshue: I like the suggestion as well. Can we say yes these can be closed and tagged, then we can move on?

AWK: So if we indicate in the respones that we are tagging these for implementation followup and close, does that meet the need?

Steve: Yes, I'm trying to be courteous.

David: It is a substantial comment. Its really hard to do on PDF. We may want a fallback position of applying this SC to markup languages.

<AWK> https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-10#Proposed_response_to_467

<gowerm> +1

AWK is adding labels and writing response. see link

AWK: Is there any objections to accepting the proposed responses to the survey?

RESOLUTION: Accept proposed responses to survey as ammended.

<chriscm> Sorry everyone have to step out early, or I will not get to eat lunch.

Graphics contrast

<Joshue> https://www.w3.org/2002/09/wbs/35422/Graphics_and_UI_Contrast20171109/results

Joshue: There are suggested changes to graphic contrast. Main theme: changing contrast ration from 4.5:1 to 3:1

Reviewing comments, there is a concern about borders.

Leaving the borders aside, if the group decided on 3:1 can we say 4.5:1 is desirable?

<Zakim> gowerm, you wanted to say I thought sensory was rolled into essential

gowerm: I thought one of the last versions wrapped the sensory conversatoin into it.

There was discussion about it but no resolution so no change.

<jallan> do we have to test contrast 3 ways? if you have 3 different colors next to each other, is 4.5:1 between the middle color and either of the adjacent colors enough?

glenda: There is a large burden on testing with 4.5:1 because we have to measure 3 css pixels. We have no contrast requirements for non text but 3:1 is a good first step.

Mike_Elledge: I would second what Glenda said and suggest thta 4.5:1 as AAA

Joshue: I can live with it if it can be done. Jim, Laura how do you feel about that? Can you live with 3:1?

<lisa> -1 for 3 to 1 from me

<Detlev> Jim can you crank up ypur audio?

Jim: I have been doing some testing and wondering if we need to test multiple colors, three ways.

The argument is that it is difficult to find 3 colors with 4.5 between all three. But what if the middle color is 4.5:1 to either of the adjacent colors not all of them? Is that enough boundary?

<laura> Can live with 3:1 if we have a AAA for 4.5:1

Joshue: Can you live with 3:1?

Jim: I could.

Rachael: If we are aiming for 4.5:1 long term, does taking a step by step approach create a burden on the testing tools?

Joshue: Maybe

<jallan> there is lots of research to support what AC says

Alistair: Addressing testing with mulitiple colors. At TPAC, I proposed a method that if you have multiple colors some of which are low contrast. If you delete the low contrast colors and can still understand it would pass.

<Zakim> AWK, you wanted to say that multiple commenters suggested 3:1, including Gregg V who has background with the 2.0 contrast SC that is helpful

<steverep> I would like to see 4.5:1 at AAA as well

<lisa> i would like to see user testing before we go down

AWK: Part of the reason we are looking at 3:1 is that several commenters suggested it.

Greg suggested that if you do 4.5:1 you run out of colors very quickly. To Rachael's point, I'm not sure we end up going to 4.5:1. I think we go to end user flexibility. Some people want lower contrast.

<Alex> technically 4.5 limits to 2 colors only becasue one is occupied by the background

Glenda: From a testing tool perspective, there is no way to automatically test for color contrast within these. This is going to be tested with a color picker. It won't hurt us from the tool end.

Lisa: Some people are going to want consistent contrast to support dimming screen. I think this has to go back to the users so we understand the tradeoffs.

Joshue: I'm hearing that 3:1 is the way to go. Alex, why do you think borders should be removed?

Alex: There are lots of user interfaces without borders. Modern design doesn't require borders.

<lisa> but accessibility needs the border - also for coga

Joshue: I see your point. borders if used perhaps?

<kirkwood> +1 about border point

Discussion about whether this reads as if borders, then sufficient contrast vs borders are required

<bruce_bailey> +1 for removing borders from list of things

Glenda: I think Alistair is correct that we can remove this but this comes from text boxes without clear borders.

Lisa: -1 to removing borders. We have research that shows that borders are important for low vision and cognitive users. We should be putting that borders are good in the understanding even though this doesn't require borders.

<Glenda> Will definately discuss border in understanding, but it does not belong in this SC for WCAG 2.1

<kirkwood> +1 to Lisa’s point to borders to help reduce visual confusion

<jallan> +1 to lisa

+1 to leaving borders in.

<alastairc> Happy to mention that in the understanding, but I see the requirement is slightly different.

Lisa has agreed to send issue paper to list.

alex: too much on the screen adds to cognitive load as well.

<lisa> +1 to jason

<Joshue> +1 to Jason

Jason: this requires contrast if the feature exists. It doesn't require the feature be present.

<lisa> everyone other then alex agrees with that

<Zakim> steverep, you wanted to say my general comment was that there is now no mention of what two things need to contrast

<Glenda> +1 to what Jason is saying…and that is correct. This SC is about making things that DO EXIST meet color contrast.

<JF> +1 to Jason

<alastairc> My current draft: The visual presentation of non-text content has a <a>contrast ratio</a> of at least 3:1 against the adjacent colors for each of the following:

<gowerm> +1 to Steve's point

Steve: Some interpretations and targets where adjacent color.

<bruce_bailey> wiki page does not have proposed wording

Joshue: Its in my draft but has gotten left out of current version.

<Joshue> +1 to adding adjacent colours

Discussion of adding it back in.

Steve: Are we targetting that indicators of state contrast with adjacent color or with opposite state?

<gowerm> Agree with Steve -- 3:1 between states

Glenda: This SC doesn't cover states

I didn't even try to go there.

<Zakim> gowerm, you wanted to say if the border exists, shouldn't the border have sufficient contrast?

<alastairc> My personal draft: https://rawgit.com/alastc/wcag21/graphics-contrast/guidelines/index.html#graphics-contrast

Gowerm: Also agree with Steve to include states. I think we can include it. I also think if a border exists, it should meet contrast ratio.

<lisa> some refrences

I would be concerned with taking that out.

<lisa> Don't make me think revisited, Krug

<lisa> "Flat design hides calls to action" - Neilson Norman Group

<lisa> Design choice is more than just about taste its an accessibility-issue - Neil Milliken

<lisa> Why hollow icons are more work for your users and ultimately create cognitive fatigue - Aubrey Johnson

Glenda: Can we cover it with techniques or failures?

<KimD> *Lisa, do you have links for those?

<Zakim> bruce_bailey, you wanted to say that borders on text boxes covered by focus indicators and visual information used to indicate state

Gowerm: It would be difficult to use techniques if it is not called out here.

<KimD> *Lisa, do you have links for those?

bruce: I'm swayed by Alex's concern. Borders being true or false is a continuum. The other content is testable. They are there or not. If we add border, we need to define it which would push this to 2.2

<gowerm> I agree with comment that defining what a border is is tough, just don't agree that leaving it out is great either

<Joshue> ak jallan

<Zakim> jallan, you wanted to say state only?

Jim: I'm concerned that we don't have the basic control. I don't want to hunt for the control so I can click on it. Its become minimalist. Under control can we have a container or something so its not just a border?

Joshue: It could say borders or containers

<Glenda> We should not force design. The minimalist design is a usability problem for everyone.

<lisa> Also see https://github.com/w3c/coga/blob/master/issue-papers/flat-design.html

<Joshue> but we dont want to look like these things are required

Alastair: If you visually highlight this as a control, it should have contrast.

<alastairc> NB: Active in this SC means not disabled, not that you are already interacting with them.

<bruce_bailey> +1 to what Glenda is saying about identifying controls being a different SC

Glenda: I think that the COGA SC has the opportunity to deal with the minimalist design of controls. I don't want to impose design. This is, if you put something on the screen, everyone should see it.

<Makoto> +1 to Glenda

<JF> +1 to Glenda as well, with the additional comment that we MUST revisit that SC soon (real soon!!)

Jim: I think my confusion was that state of active user was that it was already clicked in.

Bruce: Youhave to get back to active user part.

<jamesn> http://www.cssdesk.com/2g7MM

James: Where the border is used to identify the control, then it should have a high contrast. See link. Where the top one would pass, the bottom wouldn't because part of the border doesn't meet it even though it is still identifiable.

Joshue: Do yo think then we shouldn't specify borders?

<Glenda> +1 to jamesn (let’s drop border)

<alastairc> +1

James: I think something needs to specify border. In CSS it has a specific meaning. I think there should be something that meets the ratio. Hopefully it would be consistent across the interface.

Joshue: Container may work.

<gowerm> how about "outline"?

<bruce_bailey> Nice example @jasmsn -- the more accessible version fails the SC, but the less accessible version with no border fails

<alastairc> We need to 'load' visual indicator and explain that well

<alastairc> sorry, I mean: " visual information used to indicate state"

Joshue: People could live with 3:1 as a ratio. There is a potential issue around borders. We have a category of controls.

<bruce_bailey> oops, the less accessible version with no border at all *passes* the SC

We might need to specify outline or part of an outline of an input element

<steverep> Visual indicators of type/existence, focus, state....

<jallan> my confusion stemmed from "indicate state for active user interface components" meaning "active" vs "disabled", not "on the screen" vs "focused". apologies for not using my technical language filter

I hear that people can't live with dropping borders.

<alastairc> https://rawgit.com/alastc/wcag21/graphics-contrast/guidelines/index.html#graphics-contrast

Alastair link is current language.

Joshue: We will need to leave this open until tomorrow.

<Glenda> can we have a resolution on 3 to 1.

<alastairc> I have two small comments for the group as well, dealing with outside comments.

<Zakim> steverep, you wanted to say that not selected, not expanded, etc. are also states

<jallan> bruce, the first example has a bottom border (line), indicator of form control

RESOLUTION: Leave Open, discuss tomorrow. Issue around borders, most can live with 3:1

Joshue: Can anyone not live with 3:1 ratio?

<JF> +1 for 3:1 ratio

<JakeAbma> +1

<Joshue> +1

<gowerm> +1

<Makoto> ;1

<steverep> 4:5:1 at AAA

<Brooks> +1

<Glenda> +1 fpr 3 to 1 ratio

<Detlev> +1 fpr 3:1

<alastairc> +1

<Mike_Elledge> +1

<Makoto> +1

<Alex> +1

<KimD> +1 to 3:1

<jamesn> +1

<jallan> +1

<marcjohlic> +1

RESOLUTION: 3:1 ratio has been accepted.

<jallan> +1 steve

<laura> +1 with 4:5:1 at AAA

<kirkwood> +2

<gowerm> I think the Graphical objects def may address border

<kirkwood> +w1

<kirkwood> +1

trackbot, end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

14 Nov 2017

Attendees

Contents

Schedule for the week

CFC for Character Key shortcuts

Zoom Content: https://www.w3.org/2002/09/wbs/35422/ZoomContent_20171109/results

CFC for Character Key shortcuts

Graphics Contrast and UI Component Contrast: https://www.w3.org/2002/09/wbs/35422/Graphics_and_UI_Contrast20171109/results

Responses to comments https://www.w3.org/2002/09/wbs/35422/ZoomContent_20171109/results

Graphics contrast

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output