Accessibility Guidelines Working Group Teleconference -- 12 Jun 2018

<alastairc> regrets?

<alastairc> rssagent make minutes

<laura> Scribe: Laura

agenda+ Repository move https://github.com/w3c/wcag/

ac: big thank you to MC for moving repo
... don’t open new issues on 2.1 repo
... use wcag repo
... mc has moved one of the issues from 2.1 to wcag as a test.

MC: will cause a flood of email when issues are moved.
... not ideal. script stalled.
... better that copy and paste.
... moved tech branches but not understanding.

Silver requirements (Shawn)

<MichaelC> https://w3c.github.io/wcag/21/guidelines/

ac: document to share with WG

shawn: early draft

<alastairc> PReview URL: https://w3c.github.io/silver/requirements/

shawn: high level. revists problem statements.
... 2 parts: Design principles & Requirements.

js: Major changes. No backwards compatibility. No A, AA, AA levels.
... no mobile use cases.
... will be doing prototypes over the summer

shawn: will be having a survey.

chuck: what does not requireing levels?

js: will use a different model.

brooks: explain beyond mobile?

js: doing a comparison.
... look for a way to include authoring tools and user agents.

Non-text contrast survey https://www.w3.org/2002/09/wbs/35422/non-text-contrast/results

ac: thank you shawn and js
... had a survey.
... 6 responses so far
... explains background from last week.
... first question: Do you support the proposed testing criteria?
... results spilt down the middle.
... john says Need to be careful about 4-2 above, in that a change of color *alone* is also insufficient (ref: SC 1.4.1) but overall, yes, I agree with this as the intent

MG: My feeling is that a key pain point here is what is meant by 'identify" in the first bullet's text "Visual information required to identify user interface components".

It remains unclear to me whether "identify" encompasses an idea of understanding the role (i.e., intended interaction) of a component.

mg: I think it's fairly easy to make the argument that the visual cues that make up a component help establish its identity.
... But I hear a lot of understandable difference of opinion on the degree to which any visual element is essential in determining that identity and must therefore meet 3:1.
... first question needs to be split up. One consideration is the Existence of some kind of indicator.

ac: what would you change?

mg: border on its own should not change this.

JF: there is also the question of state. Border would be sufficent.
... example: printer icon

ac: printer icon would come under the second point.

jf: the way it is written could be misunderstood.
... can’t just use color alone.

<alastairc> https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

jf: it is slippery.

ac: reviews understanding doc examples
... you can rely on color if it meets the contrast differences.
... can’t disagree.
... we trying to achieve something different
... need sufficient contrast.

jf: need to square this with SC 1.4.1

<JF> SC 1.4.1: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

ac: #8 is similar.

MG: we have a technique that applies. It uses relative luminance.

JF: need a technique then.

mg: tasked with writing one.

ac: decision tree is just for us.

brooks: G183 is the technique. It has more requirement.
... Need additional info.

MG: in many cases, a focus indicator is not placed when an item is clicked with a mouse.
... So in example, if you click a checkbox with a mouse, although the state of the checkbox is changed, no focus state occurs with the default UA
... So, what would the requirements be where an author is doing the same?

ac: that is part 2 of the survey.
... deserves it own discussion.

mg: button with no text label will fail the first one.
... just the existence thing then we can go ahead.

<alastairc> Examples: https://alastairc.ac/tests/wcag21-examples/non-text-contrast.html

brooks: have a concern. affordances are important. don’t want to miss them.

ac: goes beyond the scope of the SC.

brooks: not for AT users.

<Zakim> JF, you wanted to say I've seen square radio buttons and round checkboxes thanks to scripting and CSS

ac: everyone would be confused. usability issue.

jf: it is about perception.

mg: visual indicators below 3:1 should fail.

JF: shape (round or square radio buttons) doesn’t matter.
... can’t use this SC to fail it.
... maybe shapes for 2.2

david: few things are weird.
... should have statements not questions.

ac: this is just a tool for us

Rachael: unclear on focus state

ac: adjusting the wording.

david: not a failure not to provide a boundary.
... need to clarify.

ac: concerning identity. not trying convey role with is SC.

MC: just the existence. boundary is a secondary issue.
... visual cues beyond label will be important.
... would radio button with text pass.

ac: would not pass unless
... 14 and 17 on the example page
... veering towards a fail.

<Zakim> gowerm, you wanted to talk about boundary and to say this label issue is awkward

MG: a lot of fuzziness on this.

ac: need to see a check box.

MG: can we qualify “identify”?

<jallan> scribe: jallan

jf: many issues

<laura> jf: lots of compound issues.

<laura> … label is not sufficient.

jf: identify = visually perceive. Makes the concept more understandable
... does that address concerns

<laura> …switch out ”identify” with “visually perceive”.

<laura> mg: that is the pain point.

<laura> thanks.

mg: text existing for everything except button is not sufficient

dm: agree, but don't see in the SC language. Lots of work in understanding

<gowerm> +1 "required to identify" gives us some muscle. We just need to agree what we want to do with it

ac: 'required to identify' gives flexibility

brooks: why reticence, none text contrast should be 3:1. what is the issue?

ac: may make issue worse. don't want to make buttons that authors tweak or remove boundaries to meet the SC and make the affordance worse
... had a test where buttons were fine before, then they were tweaked to meet the SC, and made the buttons worse.
... reviews history in the last few weeks about this issue

dm: button, gets focus, color inverts. as long as it has good contrast it is ok?

ac: yes, see steps 3 and 4

dm: if they just use the default is that ok?

ac: that's the next question.
... discussed
... identify, change of color alone,
... any disagreements about the decision and process

<Zakim> gowerm, you wanted to say it is non-essential visual flourishes

<laura> s/High level. Revisits problem statements./high level. Revisits problem statements./

mg: look at #2 github example. tab panel. the panel is 3:1 but other parts fail. buttons get some slack because it is interactive. we don't want people to remove secondary visual information that is useful to many
... and force all parts to be 3:1
... focus and selection state are critical on tab panels

Part 2 - determined by user-agent

ac: "except" ...

<laura> s/what does not requiring levels?/what does not requiring levels?/

ac: narrow definition or broad definition
... default focus does not meet 3:1 on Mac. on Windows just barely. example 7 shows default focus across browsers
... in wide definition - it fails. because the author set background color to white.
... if we use wide definition then all authors are required to repair browser behavior.
... also issue about focus on click
... if you change foreground, you must change background. file browser bugs.

lc: if you touch it, then do it right

dm: if I change a button, is focus indicator also part of that.

ac: need to make a decision about it and move on.

jf: if you change 1 color change both. poor browser implementation is on them not us.

ac: if you change the background to WHITE... then everything fails?

<gowerm> +1 we just have to say 'ugly shmugly, indicate focus'

<alastairc> q

jf: yes. the author changed something. if you change one color, change the other
... why is this controversial?

ac: author uses default focus. are they off

<david-macdonald> "or where the appearance of the component is determined by the user agent and not modified by the author;"

jf: UA guidelines. no info on focus

https://www.w3.org/TR/UAAG20/#gl-interaction-highlight

all of UA guideline 3 is about highlighting, focus, enabled/disabled elements

jf: states - active, focus, visited. many authors defined these

ac: we are putting a UA problem on the author.
... see wai site. FF on Windows will reverse focus color when it sees a dark background
... if you like default focus outline. with the wide interpretation of the exception. then everyone is required to change the focus indicator.

brooks: not if they did not change foreground and background color on a page

ac: see example 5, shows default focuses. some of the browsers do good things an we would stop them

mg: "'identify' incorporates both an indicator of a component's existence as well as visual elements necessary to understand its role/purpose"

dm: that's not all we said.

mg: this is the start of a summary.

<david-macdonald> identify that it is interactive

mg: extends beyond existence and we are working on it
... also some separation from body text

ac: UI text components are covered, we have color covered.
... issues with inputs need more than text. there is some indicator necessary to know it is interactive

dm: we seem to be in disagreement with what we published. if you change the color of a button then you need to change the focus indicator.

<laura> s/what does not requireing levels/what does not requiring levels mean?/

dm: if you touch the focus indicator then make it right, if you use the default then off the hook.

ac: this is the narrow interpretation.
... what is the def of "required to identify"

dm: Required to identify that component is interactive
... id what 'it' is , rather that 'it' is interactive

ac: understand the UI component
... nav bar ... everything in it is a link

brooks: when state changes, they you get indication of what they item is.
... focus on component existence. what visual cues are needed before you interact with it.

ac: visual indicators identify a component. where you rely on visual information for identification, then you must have contrast
... see examples funka
... showing states
... in order to identify the component need contrast.
... focus on what is required to identify
... underline gets thick on focus. example 12a

dm: example 10, focus indicator fails on safari. why would it fail if it works in other browsers.

ac: if narrow view - you haven't touched it, then it passes.

dm: it comes down to authors 'conformance statement'

mg: author make a claim... only work on X browser.

dm: conditional pass statement, depending on browser.

jf: there are lots of ways to fail that are not written a failure techniques.

dm: wcag does not say must pass on windows or mac
... need to qualify the 'fail' examples - there are browser issues.

ac: are we happy with 'identify' aspect. indicators of component existence. would like to keep flexible for what authors can do.
... add examples for buttons. show passing things
... need to update understanding.

dm: need to qualify what fails.

mg: 'identify' incorporates both an indicator of a component's existence as well as any existing visual indicators that are necessary to understand the component's identity

ac: example page is useful for discussion.
... EXCEPTION... narrow vs wide interpretation.

dm: what public want is sufficient focus indicator.

brooks: file bugs on browsers, encourage authors to make clear focus indicators

ac: if basic website, and they use default focus indicator and changed background to white. are they ok?

dm: yes

ac: narrow view

jf: if they changed background color. then not ok. they changed something. must be consistent! it is replicatable. if you change one you must change the other
... Automated testing - if foreground changes then focus must change.

<alastairc> Straw poll: Should we take the narrow definition? i.e. a website that decares background of white, and uses deafult focus styles, should it pass? +1 for yes

brooks: +1 to JF. not seeing focus is catastrophic failure.

<JF> Starw Poll: -1 If you change one you must change the other.

<david-macdonald> -1

<JakeAbma> -1

<Chuck> -1

<Brooks> -1

<Makoto> -1

-1

<gowerm> +1 yes, i think that is a severe edge case.

<david-macdonald> +1

dm: didn't change mind, changed understanding

<KimD> +1 (?)

dm: double color focus indicator.

ac: no, just pick a color that contrast with button or background

<gowerm> yes i can live with it

<laura> can live with it.

ac: can we live with wide view.
... will make a CFC

Techniques, signing-up & process https://www.w3.org/WAI/GL/wiki/Wcag21-techniques#List_of_Techniques

ac: Please write a technique, Just do it
... any questions, email chairs.
... sign up.

gm: identify' incorporates both an indicator of a component's existence as well as any existing visual indicators that are necessary to understand the component's identity

dm: identify' incorporates both an indicator of a component's existence as well as any existing visual indicators that are necessary to understand the component's existence

ac: assumptions are at the bottom of the examples page.

trackbot, end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

12 Jun 2018

Attendees

Contents

agenda+ Repository move https://github.com/w3c/wcag/

Silver requirements (Shawn)

Non-text contrast survey https://www.w3.org/2002/09/wbs/35422/non-text-contrast/results

Part 2 - determined by user-agent

Techniques, signing-up & process https://www.w3.org/WAI/GL/wiki/Wcag21-techniques#List_of_Techniques

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output