<Detlev> scribe: Detlev

AWK: Look at surve if you haven't yet

<AWK> +AWK

https://www.w3.org/2002/09/wbs/35422/1_4_11_intent/results

AWK: issue around 1.4.11 Text cntrast
... Comment on survey and github (on understanding)
... needs addtional clarity
... email was sent, survey set up
...aim: verify intent of SC

Charles Adams: Intent for internal deliberation or publishing

AWK: internal

Charles: correct that yellow is only an issue if there are no alternative means to identify focus

AWK: Is linked to identifying things by color alone
... Funka commented that a contrast ratio against background needs additional border - expressed concern that designers will reject that
... held that it is sufficient to idenify in other ways that there is an interactive control
... refers to the items / contrast examples referred to in survey
... Jake said that full boundary may be required for identifying active region - grey area

<JF> Would the addition of the word "visual" satisfy Jake's concern?

AWK: Have responded that other information might vary - button ma have underlined text, focus/hover state, cursor changes
... Concern is if we have to indicate full boundary we might run into trouble / get pushback

Jake: concern is that it may be a judgment call of the person - is "other information" present, sufficient?
... JFs had suggested adding "visual"
... to qualify other information

AWK: visual is clearly required, not alternative text

JF: Wants to emphasise visual - agree swith the Gestalt argument - visual information meeting contrast requirements should be OK

<Joshue108> I'm also a +1 to Gestalt

AWK: Asking Marc about hover and focus state

Marc: Why not have hover state the same as focus state - easy way to resolve it, but others may disagree

Brooks: refers to rationale that keyboard user experience with high contrast is treated differently from mouse user focus, it is different (they position the mouse cursor, so the same strong indication is not needed
... may interact with other SC Concurrent input mechanisms - if you don't know where the (mouse) focus is, it migh tbe diffcult to pick up with a keyboard

AWK: Alex commented that alt text should pass but unclear how he meant that

David (explaining Alex' line): If you have other information that would help pass it

<AWK> Detlev: Concerned about pointer users that can see the pointer so know where they are

<AWK> ... hover supports the interaction but isn't crucial for identifying the control

<AWK> ... hover wouldn't be required

<jon_avila> we don't require visual affordance

Detlev: Explaining why I think that hove should not be required

<jon_avila> I agree with Andrew that graphical contrast still has to pass during hover

AWK: Point that hover may reduce contrast so that would be a problem

Detlev: agrees

AWK: reading Makoto's and Mike Gowers survey responses (check there)
... relating gowerm's point that the ratio only kicks in if there *is* a boundary
... Refering to the visual quiz (US states): here you needed to see selected State in contrast to other states

gowerm: There is wiggle room in understanding as how we see boundary
... two examples: Text input with boundary - more recent versions with one line at the bottom. They should both be seen as boundaries.
... second part is where boundary is needed to show that something exists
... may not be clear with just text - is it interactive? Esp. if control text ar ethe same as body text
... especially buttons are an issue as they may not cause pointer change

Brooks: Not just a matter of determining if something a control - boundaries can communicate expectations (such as boundaries in a button) - lighr grey chackbox may be unclear to user

<jon_avila> we don't require that buttons have borders though -- we say no border is acceptable and we may force designers in that direction if we require higher contrast borders/background

Brooks: important to be able what type of control it is

David: At this point we need the most liberal interpreatation possible - subscribes to Gestalt factor.

<jon_avila> Agree with David that it's separate from this discussoin

David: accessibility issue was defined as something that disproportionately affects PwDs - that may not be the case - research is missing to determine whether these problems affect people disproportionately
... Many have spent a lot of money on their design, they may reject requirements if they mess up their design

JF: not having problems educating designers on contrast issues (e.g. orange problem) so we need to educate people - not be so liberal that the point of this SC is missed

AWK: If info in a color is needed it has to meet that ratio - if the info is suppied redundantly it might be OK

<AWK> Detlev: my point about the hover state is that it isn't needed to have contrast between default and hover state

<AWK> ... you can't have both without running out of colors

Detlev: clarifying he refered to contrast requirement between default and hover state

AWK: People seem to be in general agreement
... second question: Alternate SC text - most think the statement is more accurate

<AWK> "Visual information @@required@@ to indicate states and boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;"

<Brooks> Defining role="button" for an interface control provides a basic set of expectations for assistive technology users. For low-vision and colorblind users, providing low contrast non-text control boundaries is like stripping the "role" from the control. Ambiguous input boundaries doesn't support equal access to control type.

<AWK> Visual information @@necessary to understand@@ states and boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

goverm: It seems to say "Where visual info is necessary to understand state or boundary contrast is required" but this is not what the text is saying
... Does not clarify when a visual boundary is necessary

<Chuck> I want to make a very minor change to the text: ...and IS not modified by the author;

AWK: The question now is how we deal with comments. There is a very contrained scenario that allows to change SCs before publication - if people agree that the changed text will more accurately reflecting the intent - via a very small text change in 1.4.11
... changing to "necessary to understand" - if people agree, we can make the change; if there is no agreement, we can leave text and clarify meaning in Understanding doc, then make changes later in Errata or in WCAG 2.2 (if that happens)

David: Word "required" in the second bullet - so there is a precedent
... we can't rewrite - we ashould change it by adding "required"

AWK: "required to understand" - that may make the difference

<Joshue108> right

gowerm: visual information required to understand..
... does that cover concerns about button?

David: Agrees that this needs to be explained in understanding doc - new language easier to hang explanation on

AWK: still needs work in understanding - agrees with David that language makes it easier to explain, give some room
... Have been reluctant to be tto prescriptive (e.g. pixel width of boundaries) - there are so many types of controls and so much is without specific boundary, many possible permutations with background etc

JF: It is not so much the boundary but a visible focus - but color contrast for focus was never defined - now this defines a minimu contrast requirement for tab focus
... we need to discern that something is focusable - so the emphasis on boundary might be confusing the issue

AWK LV task force was clear that visual contrasty focus was very important

<Zakim> gowerm, you wanted to say can someone explain which boundaries in particular this was addressing?

gowerm: recollecting what controls were havign a boundary where we wanted to ensure 3:1 contrast - not button...

Jon: Concern that if we don't reqire boundaries, this might make designers to remove light boundaries altogether which could make things worse

<david-macdonald> Visual information @@required@@ to indicate user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

Jon: boundaries of input fields are important to direct clicks; pointer change can help but is not always guaranteed

<david-macdonald> q

Jon: A boundary with less contrast is better than no contrast / indication

<david-macdonald> Visual information @@required@@ to indicate user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

David: suggestion for first sentence - leaving out 'boundary' focusing on visual information

<JF> +1 to side-stepping "boundry" alltogether

<kirkwood> +1 to removing as david’s suggestion

<david-macdonald> Visual information required to understand user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

<Chuck> +1

<kirkwood> +1

JF: likes suggestion

<AWK> Visual information @@required understand@@ user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

<AWK> Visual information @@required to understand@@ user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

gowerm: that language doesn' bring clarity on buttons
... first bullet would then only be about states

goverm: you need to answer the question whether a button without outline makes it clear that it is a button

Jon: Would Funka controls pass? Tabs or links?

David: The context helps - if it is a form and you have the word submit, it may be clear
... weary of being too prescriptive

Jon: refering to form fields with labels (examples in mail) - not sufficient
... You don't it is an input field

David: Form context would probably clarify that

next scribe?

David: everyone seems to know what a form is and not use that contextual info

Jon: SOme suff it is unclear whether it is actionable but that may not be solved in this SC

<jon_avila> scribe: jon_avila

chuck: track of precision of what we are debating changing. Does it solve some problems, introduce some problems? I don't see that it introduces some problems.

awk: Say a button has a printer that has parts that are low and high contrast but you can still figure out what it is without the low contrast. You'd be able to understand where that button is.

MG: A button has a text label as part of the UI where others are external to target. How many people think it's ok where there is nothing around the button?

<JF> +1 to AWK

awk: Not agree that buttons always have text.

mg: If it's a graphic it's caught by 2nd bullet.
... you can still see the button by the text.

awk: user testing might bear that out that user may not like it being light. Some people may want a thick border.
... gut feeling that users with disabilities may not find or more problematic than otehrs.

<KimD> I don't like an essentially invisible background to a button, unless there's a boundary

<AWK> like this one: https://knowbility.org

mg: take a magnifier icon. The graphic itself is an indicator. If I extend the same thing. As long as text meet the text requirement. Still lot of problems of whether it is interactive or not -- but they can see text

<JakeAbma> example: https://www.ing.nl/privatebanking/index.html + zoom in a bit, you'll see a 3:1 icon for search

<JakeAbma> button

jf: there is a boundary -- it is the magnifying glass.

mg: boundary is supposed to be target boundary

jf: if I tab onto button - we need some visual indicator above color alone. Will need some focus indicator beyond color. You get border on focus
... concerned that we are getting too caught up in boundary

detlev: some elements are conventional. How is important to know that is slightly smaller or larger. What about triangle with boundaries.

<AWK> JonAvila: think that in some cases the boundary is important and in others it isn't

<AWK> ... sometimes I click on the page to get focus there so I can scroll and can accidentally click on something

<AWK> ... what we need to figure out is whether the boundary is needed for PWD to figure out something to help operate the page

<AWK> ... if using the keyboard then you tab to find out - is this an additional burden?

<AWK> ... an important issue but separate.

david: 10 or 15 conversation have seemed historic. This is important conversation. Because it could cause so much change based on what we say now.
... removes necessity for boundary and address concern of less accessible things by designers not using boundaries
... might take us back a step to just focus on states. my proposal would give us opportunities.

KimD: if you have a two part button such as drop down -- the boundary helps users that the down arrow is associated with the icon since there is no text it becomes confusing.

awk: debate in itself - spacing may make an impact on identifying control and it's parts

<Zakim> gowerm, you wanted to say that we can't stop crappy UI with an SC

mg: I don't think we can stop crappy UI design with an SC. Is it better to have all boundaries be 3:1 or have no boundaries. Would removing little gray things make it less comprehensively.
... trying to tackle things that are most important for accessibility
... leaves a lot of questions about boundaries to controversial decisions

brooks: Could use a different word than boundaries.

<AWK> rrsaagent, draft minutes

<david-macdonald> Visual information required understand user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

brooks: We have focus on whether the control has focus, etc. but have not focused does the user know that type of control they are working with.
... May have to make it clear that the SC does not require certain contrast minimum for the parts that indicate the type of control

awk: This change text helps and the understanding document will help more.
... What I am hearing is that the text for 1.4.11 now confuses that.
... Any other thoughts?
... Is it identify or understand UI components? Indicate is what we have now.

<gowerm> Visual information used to indicate states and understand boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

mg: I think state information should be required.

<AWK> Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

awk: does this language feel ok?

<marcjohlic> +1

<JakeAbma> +1

<Chuck> +1

<Kathy> +1

<david-macdonald> +1

<Detlev> +1

<kirkwood> +1

<Makoto> +1

awk: I will ask if there is any objection and putting this forward as the view of the working group for the w3c management review.
... will put it forward that we are happy to go forward not just as happy

mc: wording is fine. It would be helpful beyond the working group to see if this is satisfactory to others outside of the working group

<Joshue108> +1

awk: any objection to making this change and putting it forward

<gowerm> +1 to Jon's statement. it's removed "Boundaries" but otherwise has no clarified things.

david: easiest way is to say put a border but it provides flexibility to do other things.
... should result in more visual indicators that have sufficient contrast

<Zakim> gowerm, you wanted to say I'm also seeing a lot of interpretation for this: 'Visual information required to identify user interface components". I think it's going to create lots

mg: removing boundaries removes one thing that people will ask about

awk: will reduce but not eliminate questions

detlev: I would have interpretedq differently that it has some indication

mg: if you are saying a button has to have a boundary then it would have to have a 3:1 ratio

awk: my understanding is that we aren't saying that a button has to have a boundary
... you are showing that it's clickable by it's text and position in relative and the cursor changing
... If it appears in a navigation bar it can be identified more readably. We've never have been super strict on behaviors of buttons vs. links
... if you have something such as a set of tabs that you need to identify the type
... githubs tab interface - has a low contrast tab shape around the active but it has a red line that indicates it's a set of tabs

marcj: So we are switching indicate to identify. Is that correct?

david: like identify better

Publishing Understanding

no

RESOLUTION: Accept change to 1.4.11 Non-text contrast in order to better reflect the intent of the WG, and propose change to W3M.

awk: need to work on understanding documents. Will need to work on it for next few months. What we need to do in next day we need to wrap up what we have so we can publish new current state.

mc: would prefer a bulk understanding thing that is good enough to accompany this next week.

awk: because we are publishing the understanding docs that are not in the TR space we can fix things.
... we can make changes after that much more readily and say we had the CFC approved Friday and immediately after that someone suggests a change that could be published it all goes live again.

mc: we need to come up with a process that Michael is tasked with updating

awk: we will ask people to agree that it is read to go out in conjunction with WCAG 2.1 release.
... People will undoubted find spelling error and we will fix because it's editorial. If they say they aren't happy with a paragraph we will ask you if you can live with the understanding change for today because we can change it. It's not a six month process.
... Do people think the understanding documents have evolved to a state that they are pretty good.

<Detlev> +1

awk: Does anyone not think they have evolved.

RESOLUTION: send out CFC for publication of understanding documents with the rec

mc: working on announcements.

awk: need to respond to commenters.

mc: possible we will put forward some editoral changes to abstract
... techniques have not yet been published their location but somehow do before next Tuesday

awk: later this week the director is reviewing the transition request and assuming it goes through and is approved then we are looking at next Tuesday as being a big day.

<Joshue108> good work all.

<gowerm> +1

awk: thanks for everyone's hard work over the last 18 -24 months. We are close to the finish line but once we pass we still have to run fast.

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/requioremt/requirement/
Succeeded: s/haviong/having/
Succeeded: s/striping/stripping/
Succeeded: s/ackda//
Succeeded: s/fist/first/
Succeeded: s/forst/first/
Succeeded: s/wound/would/
Default Present: Detlev, JakeAbma, Makoto, MichaelC, Joshue, AWK, kirkwood, Chuck, Brooks, JF, KimD, gowerm, david-macdonald, marcjohlic, jon_avila, Kathy
Present: Detlev JakeAbma Makoto MichaelC Joshue AWK kirkwood Chuck Brooks JF KimD gowerm david-macdonald marcjohlic jon_avila Kathy
Regrets: Greg_Lowney EA_Draffan Mike_Elledge
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Found Scribe: jon_avila
Inferring ScribeNick: jon_avila
Scribes: Detlev, jon_avila
ScribeNicks: Detlev, jon_avila
Found Date: 29 May 2018
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)