<scribe> scribe: Glenda
<AWK_> trackbot, start meeting
<AWK_> Chair: AWK
<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference
<trackbot> Date: 15 November 2017
<lisa> i have a zoom room we can use
<lisa> are we doing any coga stuff today? (it is 9 pm )
<AWK_> We will focus on the COGA items tomorrow Lisa
<alastairc> http://rawgit.com/alastc/wcag21/graphics-contrast/guidelines/#graphics-contrast
<alastairc> "The visual presentation of non-text content has a contrast ratio of at least 3:1 against adjacent color(s) for each of the following: (Level AA)"
<AWK_> http://rawgit.com/alastc/wcag21/graphics-contrast/guidelines/#graphics-contrast
alastairc: the first part hasn’t
changed.
... the bit that has changed is bullets.
Controls
Visual information used to indicate state for active user interface components, except where the appearance of the component is determined by the user agent and not modified by the author.
<Alex> hey all, i can't get in the call. can somebody send the appropriate dial in infor?
Graphical objects
Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.
<lisa> i would not have understood that
<Alex> i need the proper meeting id
<Alex> got it
<AWK_> version from survey at bottom of: https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-11
AWK: what about against adjacent colors
AWK: contrast ratio definition in
WCAG 2.0 has reference to “contrast to what”
http://rawgit.com/alastc/wcag21/graphics-contrast/guidelines/#dfn-contrast-ratio
... suggest we go with against adjacent color(s) in this SC as
it is currently written at
http://rawgit.com/alastc/wcag21/graphics-contrast/guidelines/#graphics-contrast
Success Criterion 1.4.11 Graphics Contrast - The visual presentation of non-text content has a contrast ratio of at least 3:1 against adjacent color(s) for each of the following: (Level AA)
<Joshue108> makes sense to me
<Zakim> Joshue, you wanted to ask about the border etc issue
Joshue: want to ask about border issue? Do you feel that this addresses the questions about border?
alastairc: this is covered by “Controls: Visual information used to indicate state for active user interface components”
Joshue - that makes sense. I like this new text.
<alastairc> Look here: http://rawgit.com/alastc/wcag21/graphics-contrast/guidelines/#graphics-contrast
<Zakim> gowerm, you wanted to say there is no wording about contrast between states
<Joshue108> yeah, that was suggested yesterday - AAA for states
<JF> and I +1'd Mike's idea there
gowerm: concerns about no
contrast requirements for between states, and no contrast
requirements for disabled controls.
... wants this to be covered in a AAA
<alastairc> and remove exception for default user-agent aspect
<Joshue108> +1 from me 2
<Joshue108> -1 to between states
<alastairc> as it came with an offer of help, I'm very happy with that.
<Zakim> steverep, you wanted to go through my 4 comments in the survey
steverep: call it something other
than graphics contrast. suggest calling it graphics and
controls contrast
... don’t like the term non-text content in this sc
<alastairc> is there anything that "the visual presentation" brings?
<alastairc> Steve's suggestion: "The following have a contrast ratio of at least 3:1 against adjacent color(s):"
steverep: state - we may need to define normatively
<Zakim> Joshue, you wanted to say I also like contrast for disabled items
steverep: I don’t see where it covers boundries of something like a textbox, that is not a state. Could we say “state or boundries”. If you are not providing a boundry for anyone, you are not required to, but if you do provide a boundry, make it visible to all.
<gowerm> +1 to make it "indicate state or boundaries"
Joshue: like idea of calling this SC Controls and Icons Contrast
<alastairc> +1 to point, I think I have a better solution for the text
<alastairc> E.g. "Visual information used to indicate active user interface components and their state, except..."
Joshue: what about disabled controls?
<AWK_> "Contrast for non-text information"?
Glenda: disabled controls do not require contrast due to a need for preferences between COGA and low vision. This is purposefully left for a future version.
Alex: image of text within an icon has to meet contrast ratio.
Glenda: yes, Alex, that is already covered in WCAG 2.0 Color contrast…all text (including text imbedded in an image).
Alex: do make people debate “required for understanding”
<Joshue108> Good points Alex
<Joshue108> We could ask marketing?
Alex: (he actually said) do NOT make people debate “required for understanding”. remove this clause.
<AWK_> Alex's suggestion? Graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.
Glenda: Alex, can you live with it for this next draft (as is)? And let’s test this during implementation?
<AWK_> Alex's suggestion? All graphics, except when a particular presentation is essential to the information being conveyed.
Alex: add another exception, or if there is an image of text?
<Joshue108> I'm confused...
AWK: we can clarify “image of text” in understanding, that text (real or in an image) is covered by WCAG 2.0 1.4.3
<AWK_> All graphics, except when a particular presentation is essential to the information being conveyed or images of text.
We can have Alex’s exact example as a sufficient technique
<Joshue108> what about purpose?
<Joshue108> Parts of graphics required to understand the content or purpose..
<alastairc> Visual information used to indicate active user interface components and their state, except
<AWK_> I don't believe that visual information brings any baggage from WCAG 2.0 days.
alastair: talking about state,
let’s use “ Visual information used to indicate state for
active user interface components"
... disagree with Alex. There are very simple methods and I’ve
surveyed this, and I’m getting strong agreement from designers
and experts outside this process
Alex: I’m making it easier to test, and harder to meet (raising the bar)
+1 to what gowerm just said “to say that Alex's change in language makes it less testable. also the text portion is unnecessary as it is covered already by Contrast (minimum)”
alastair: I would agree if it was
focused on just controls and icons. But it also includes much
more complex graphs.
... includes line charts and graphs. We can’t go with what you
are suggesting Alex.
Alex: I acknowldege that for complex charts. But for controls and icons, let’s simplifiy it.
alastair: can we test this with a survey?
<steverep> -1 to controls only - this needs to apply to charts, diagrams, etc.
<Zakim> steverep, you wanted to offer James' comment about applying 1.4.1 Use of Color to difference between states
AWK: Alex if you are going to propose this…you will have to give us text for this.
<laura> -1 to controls only
<jallan> -1 to controls only
<Zakim> AWK_, you wanted to say that an internal rule for a company can be more strict
Steve: state and differences between selected and unselected / and focus and unfocused. We could go back to WCAG 2.0 1.4.1 Use of Color
AWK: even if we were to keep “parts of graphics” due to the need for very complex graphics. An individual company could have a stricter requirement internally if that makes it easier for a company to implement.
<Zakim> Joshue, you wanted to ask about purpose
AWK: if it is easier for your company to say, “Icons must meet 3 to 1” you could do that internally within your own company
<Joshue108> Parts of graphics required to understand content or purpose..
<lisa> if coga items are not on the agenda I think i will go to bed.\
Joshue: agreeing with AWK. Graphical objects - debate about what is important. Offers this text: “Parts of graphics required to understand content or purpose..”
<lisa> please send me a message on skype if i am needed
<Zakim> gowerm, you wanted to say that Alex's change in language makes it less testable. also the text portion is unnecessary as it is covered already by Contrast (minimum)
<lisa> thanks
gowerm: change the word “controls” to “User Interface Components”
<lisa> awk, sorry i did not see the message
gowerm: does graphical objects apply to simple icons with just two colors?
alastiar: I picked up “graphical objects” from ARIA and SVG. Based on gestalt principles.
alastair: see understanding at http://rawgit.com/alastc/wcag21/graphics-contrast/understanding/21/graphics-contrast.html
<laura> Gestalt principles: https://en.wikipedia.org/wiki/Gestalt_psychology#Pr.C3.A4gnanz
gowerm: the understanding document is really well done. This is very clear for designers.
<laura> +1
+1 +1 +1 to what gowerm just said
<Zakim> AWK_, you wanted to revisit title, state, and steve's other points
<Ryladog> +1
<AWK_> How about: The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s): (Level AA)
<gowerm> +1
<jallan> +1
<Joshue108> thats fine
<Joshue108> +1
<Ryladog> +1
<Makoto> +1
+1
<JF> +1
<laura> +1
<Alex> +1
<AWK_> Visual information used to indicate state or boundaries of active user interface components
<gowerm> +1
<alastairc> for 3 & 4 of steve's comments, I suggest: Visual information used to indicate active user interface components and their state,
+1 to boundaries
<gowerm> +1 to boundaries
Visual information used to indicate state AND boundaries of active user interface components
<JF> +1 to 'and' vs. 'or'
steve: and it should be state”s”
AWK: proposed “Visual information used to indicate states AND boundaries of active user interface components”
<Joshue108> as long as people dont the feel the need to unecessarily add boundaries
<AWK_> "Visual information used to indicate active user interface components and their states"
Visual information used to indicate the existence of an active user interface component and it’s states.
<Joshue108> Id prefer that..
Suggestion 1: Visual information used to indicate the existence of an active user interface component and it’s states.
<steverep> Thought about existence but didn't like it in my head... prefer to go more prescriptive with "boundaries" but can live with any
<gowerm> I think boundary is immediately more easy to grasp, and that "existence" is pretty vague but if that is worked into the Understanding document
JF: active, selected, in focus
<gowerm> John states: focused, selected
<jallan> active = not disabled, you can can still focus, hover, and select
<Zakim> gowerm, you wanted to say that "boundary" is clearer and less up to debate as long as it is clear this is not requiring the addition of a border
gowerm: prefers boundary
AWK: Visual information used to indicate state or boundaries of active user interface components
<jallan> active = non-disabled user interface components
Visual information used to indicate states AND boundaries of active user interface components
AWK: let’s add a definition for state
<Joshue108> assume nothing
Definition for State from ARIA? https://www.w3.org/TR/wai-aria-1.1/#dfn-state
<alastairc> I think that should be plural and AND? Visual information used to indicate states and boundaries of active user interface components
<gowerm> Put state examples in the Understanding doc
+1 for definition of state in WCAG 2.1
suggest using ARIA definition found here: https://www.w3.org/TR/wai-aria-1.1/#dfn-state
State
A state is a dynamic property expressing characteristics of an object that may change in response to user action or automated processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities. See clarification of states versus properties.
<gowerm> I don't think we need a state definition, given we didn't in 4.1.2
<steverep> Hmmm... forgot about 4.1.2 - would we need to link it?
<Joshue108> +1 to state info
<AWK_> A state is a dynamic property expressing characteristics of an object that may change in response to user action or automated processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities.Examples of states include focus, hover, select, press, check, and expand/collapse.
<Joshue108> that'll do
+1 to AWK’s definition
<gowerm> Yay Steve!
<AWK_> A state is a dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes. States do not affect the nature of the object, but represent data associated with the object or user interaction possibilities.Examples of states include focus, hover, select, press, check, and expand/collapse.
<Joshue108> Something about the need to make this state information accessible via DOM updates and or visible focus indicators see SC blah blah
-1 to touching anything in 4.1.2
<jallan> A state is a dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes. States do not affect the nature of the object, but represent data associated with the component or user interaction possibilities. Examples of states include focus, hover, select, press, check, and expand/collapse.
<Joshue108> we wont be going near it..
<gowerm> s/Do DO/To Do
<AWK_> Steve's: a dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes. States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities. Examples include focus, hover, select, press, check, and expand/collapse
<jallan> +1 steve, +1 definition
+1 to add definition for State
<gowerm> +1 to Steve's defn
<laura> +1 to steve
<Makoto> +1 to Steve's
<AWK_> Examples include focus, hover, select, press, check, active, visited, and expand/collapse
<Ryladog> +1
RESOLUTION: Add definition for state “a dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes. States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities. Examples include focus, hover, select, press, check, and expand/collapse”
<steverep> Don't care....3 out of 4 is a WCAG win
<Joshue108> While its a little long +1 to adding the components bit
AWK: let’s name this SC
<Zakim> gowerm, you wanted to say that we are still talking about graphics when we're talking about these UI components
Graphics Contrast is acceptable
RESOLUTION: Add definition for state “a dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes. States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities. Examples include focus, hover, select, press, check, visited/unvisited, and expand/collapse
<JF> +1
+1
<Joshue108> +1
<Ryladog> +1
<jallan> +1
<alastairc> And change controls to User Interface Components?
<laura> +1
<gowerm> Graphical Contrast?
<Joshue108> na
<Joshue108> dont like that..
AWK: Naming this SC Graphics Contrast
<Alex> i have proposal WRT what i spoke about
AWK: change controls to User Interface Component
<Alex> All part of graphics within a control, except when a particular presentation of graphics is essential to the information being convey or when images of text that is used to provide equivalent info within the control meets WCAG 1.4.3
<Alex> Parts of graphics that is not within a control and is required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.
+1 to replacing controls with “user interface controls” for consistency
<Zakim> gowerm, you wanted to say we don't need the text language
<JF> +1 to alex and josh
<Joshue108> I think it will reduce churn for testers..
<JF> "A" as an icon is an image of text
“when images of text that is used to provide equivalent info
<Joshue108> Its about communicating affordances.
AWK: this is the same problem as before
Alex: no…let’s look at the A with
arrow up, and A with arrow down.
... in both cases, the letter “A” indicates text. And that “A”
needs to meet 4.5 to 1. The arrows need to meet 3 to 1.
... let’s move to “A” with red below it, to indicate text
color. The “A” needs to meet 4.5 to 1. The red is essential, so
it has an exception.
AWK: I agree with what you are saying
Alex: highligher yellow…the yellow is essential…that is an exception.
gowerm: what about the “A” with the eraser?
Alex: the eraser would need to meet 3 to 1
<Joshue108> Lets get back to Gestalt principles..
AWK: ... what about copy format? paintbrush?
Alex: I can handle that with text.
<alastairc> 1st bullet removes everything except flat design, much harder sell to the designers.
alastair: Alex’s solution is restricting too much in controls. We need to allow author creativity. we can test for this, just not automatedly.
<alastairc> 2nd bullet means you just have to make a graph into a link (e.g. to the data, a larger graphic), it passes.
<Joshue108> subjectivity is underrated..
<Zakim> steverep, you wanted to remind everyone there is subjectivity in the definition of image of text as well
<alastairc> yep
<Joshue108> ok, thanks
alastair: what about if you have a link to more information using a complex chart, that would make it impossible to make every single piece of that complex graphic meet contrast…because it just became a control.
<Joshue108> Really, I take Alexs point about churn amongst testers but also dont want to restrict what is or is not acceptable.
steve: A with an eraser next to it, the eraser is necessary to know
<Joshue108> your saying this may mandate flat design?
<alastairc> It certainly restricts the design significantly more
<Joshue108> yeah, roger that..
<alastairc> I think we should stick to it, authoring trumps automation
AWK: straw poll, should we stick to “parts of images” or go more towards “Alex’s proposal”
<alastairc> +1 parts
+1 parts
<gowerm> +1 parts
<laura> +1 to parts
Alex can do something more restrictive with in his company
<steverep> -1 to restriction to controls or mentioning images of text at all
<marcjohlic> +1 parts of images
<JF> +1 with some hesitation (I feel Alex's concern, but agree with Josh)
<AWK_> Alex: All part of graphics within a control, except when a particular presentation of graphics is essential to the information being convey or when images of text that is used to provide equivalent info within the control meets WCAG 1.4.3 (next bullet) Parts of graphics that is not within a control and is required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.
<AWK_> Alastair: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.
alastair: and we do need to prove inter tester reliability
Alex: daily cost of subjectivity. concerned about impact from legal perspective (lawsuits). concerned about the churn of compliants.
<Joshue108> but they have to prove intent/neglect etc
alastair: you can apply that to
many of the current SC, especially 1.3.1 and 1.1.1
... let’s hold it to the same bar as WCAG 2.0
<Zakim> AWK_, you wanted to try to wrap it all up
Glenda: rejects the potshot angle
<Joshue108> +1 to parts
AWK: hearing more support to go with Alastair’s suggestion, but also hear Alex’s concerns. Propose adding an editor notes about the concern for subjectivity (for a working draft).
Alex: no
<Joshue108> yes
<alastairc> how does that not happen for upteen other SC??
<Ryladog> +1
<JF> +1 to 'yes there is subjectivity to SC' - for example Alex, what is "appropriate" alt text?
AWK: leaving with alastair’s language and adding an editor’s note for Alex’s concern. Does anyone object?
Alex objects.
Anyone else? No other objections. Significant group support with only 1 objection.
AWK:
<AWK_> Editor's note: The Working Group is interested in feedback on challenges evaluating images to determine what parts are required for comprehension of content.
<AWK_> Editor's note: The Working Group is interested in feedback on challenges evaluating images to determine what parts are required for comprehension of content, and whether the Understanding document helps address the challenges.
<Joshue108> looks good
<marcjohlic> +1
+1
<jallan> +1
<Makoto> +1
<JF> +1
<gowerm> +1
<laura> +1
<Ryladog> +1
Alex: replace “helps” with “resolves”
<AWK_> Editor's note: The Working Group is interested in feedback on challenges evaluating images to determine what parts are required for comprehension of content, and whether the Understanding document clarifies how to resolve the challenges.
<laura> +1
<Ryladog> Techoque and Understanding maybe
<jallan> would be useful to have a page of example images that are in question. Include a statement of the problem. for picture of Erase All format, Increase font size, etc. what parts do you check for contrast? what is required for comprehension?
<Zakim> steverep, you wanted to say this kind of parallels my concerns over piping everything into essential which requires significant evaluation
Joshue: Alex has good points and constructive conversation. But I see this as iterative. In the meantime I think something in understanding and sufficient techniques can make this reasonable to test. We want to reduce churn and increase certainty.
<Joshue108> +1 to Jim
Steve: I would also request consistency on evaluating essential exceptions.
<Makoto> +1 to Jim
<alastairc> yep, I want to include lots of examples. It might be a rather large doc...
<Joshue108> good stuff
<jallan> AC, a github page or one of your great blog posts. will help
<jallan> ... need to get comments
Alex: commenting on the understanding document
Alastair: we have not folded in the understanding documents from both SC (they were split)
<Joshue108> dont see the resolution..
trackbot, end meeting
<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference
<trackbot> Date: 15 November 2017
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/CPGA/COGA/ Succeeded: s/Chair: Joshue108/Chair: Ad hoc/ FAILED: s/Do DO/To Do/ Default Present: AWK, Glenda, Josh, Alex, gowerm, steve, JF, MichaelC, alastair, Laura, Makoto, Katie, Lisa WARNING: Replacing previous Present list. (Old list: AWK, Brooks, Crystal, Detlev, Glenda, JF, Jim, Joshue108, Katie_Haritos-Shea, KimD, Laura, Makoto, Mike_Elledge, Rachael, SteveRepsher, bruce_bailey, jamesn, jasonjgw, kirkwood, lisa, marcjohlic, shadi) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, jasonjgw, JF, Mike_Elledge, Joshue108, Rachael, kirkwood, KimD, Jim, marcjohlic, Crystal, bruce_bailey, Detlev, Brooks, SteveRepsher, Makoto, shadi, jamesn, Glenda WARNING: Replacing previous Present list. (Old list: AWK, jasonjgw, JF, Mike_Elledge, Joshue108, Rachael, kirkwood, KimD, Jim, marcjohlic, Crystal, bruce_bailey, Detlev, Brooks, SteveRepsher, Makoto, shadi, jamesn, Glenda) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, Glenda, Josh, Alex, gowerm, steve, JF, MichaelC, alastair Present: AWK Glenda Josh Alex gowerm steve JF MichaelC alastair Laura Makoto Katie Lisa Found Scribe: Glenda Inferring ScribeNick: Glenda Found Date: 15 Nov 2017 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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.)[End of scribe.perl diagnostic output]