<Mike_Elledge> scribe: Mike Elledge
<AWK> +AWK
<Mike_Elledge> ac: Happy new year everyone!
<Mike_Elledge> ac: CFC's first item. Obsolesence and retriing WCAG 1.0, and related WCAG 2.0 docs from before publication.
<Mike_Elledge> ac: Have rec'd emails, no questions.
<Mike_Elledge> ac: If you have them, pls ask now.
<Mike_Elledge> ak: Wanted to remind people that there are two items: 1.0 and 2.0 related docs.
<Mike_Elledge> ac: 2.0 has fewer responses so far.
<jeanne> Email with the Silver draft: https://lists.w3.org/Archives/Public/w3c-wai-gl/2019JanMar/0010.html
<Mike_Elledge> ac: Want to check if we have Kathy yet. She'll join in 40 minutes.
<Mike_Elledge> ac: Pull Silver up first.
<Lauriat> Silver Conformance Draft link: https://docs.google.com/document/d/1wTJme7ZhhtzyWBxI8oMXzl7i4QHW7aDHRYTKXKELPcY/edit
<jeanne> Proposal for the Silver Conformance Draft: https://docs.google.com/document/d/1wTJme7ZhhtzyWBxI8oMXzl7i4QHW7aDHRYTKXKELPcY/edit#heading=h.yj2271xdugi3
<Mike_Elledge> jeanne: Working in coformance for many months. Many moving pieces, trying to work out details. We need input from wCAG earlier.
<Mike_Elledge> j: If we missed something or if there's a better way, best to get it early. Doc is draft and want input about how to solve some issues we have.
<Mike_Elledge> j: Link is in IRC. First, this does not replace prototypes, works with info arch and language, this is the performance part of it.
<Mike_Elledge> j: it is integrated with them, which make sit complicated. We are showing guidelines and methods, and how we'd form those for conformacne (bronze, silver, gold).
<Mike_Elledge> j: Intend to update with 2.1, as well as b, s, g. Whether people can acutally use product. Fits in with conformance you've already seen.
<Mike_Elledge> j: Points add up to b, s, and j. Point scoring by functional user needs. Conformance model concerns that it wouldn't be gamed.
<Mike_Elledge> j: Don't what points loaded up at expense of other disabilities. Looking at categories, minimum pts per category.
<Mike_Elledge> j: Level is defined by overall score. Want to avoid saying some SC are more important than others. An issue with AAA.
<Mike_Elledge> j: Want to reward for ppl doing good things, but not penalizing for missing some. Need minimums, of course.
<Mike_Elledge> j: Want to include user testing with PWD. Older diagram, but have new guidelines, with methods, tests (true/false), point-scoring system.
<Mike_Elledge> j: One area is tough: methods and points. Multiple methods for a guideline: technology, difficulty, etc. Methods worth different points.
<Mike_Elledge> j: Example: Alt text is one point. But testing with ppl who are blind might get more pts.
<Mike_Elledge> j: Automated test (1), manual (3), etc.
<Mike_Elledge> j: Should there by multiple tests per method, or single method. Leaning toward multiple tests.
<Mike_Elledge> sl: Four different areas: measurable guidance=every test has a gradient wrt helpfulness; task based assessment= Task at hand, will work better for interactive vs. static pages
<Mike_Elledge> sl: Accessibility support, and flexibility are two others. Flexibility related to pt system. Won't have to re-do entire pt system.
<Lauriat> Conformance bit in the Requirements draft: https://w3c.github.io/silver/requirements/index.html#oppotunities_conformance
<Mike_Elledge> sl: Will drop in link.
<Mike_Elledge> ac: good to see it coming together. Complicated. Per instance nature how guidelines work now, vs. how they could.
<Mike_Elledge> ac: All or nothing nature of that. Are we duplicating this, leading to high and low scores?
<Mike_Elledge> ac: if you have guideline for whole page w/ multiple instances, neither way seems good: Per isntance, or entire page.
<Mike_Elledge> ac: Do you get many points, or lose all points?
<Mike_Elledge> sl: Trying to tie to user tasks. So you can tell diff betw alt text on logo (not important) vs. alt text that is crucial to accomplishing text.
<Mike_Elledge> sl: Haven't figured out yet. Depends on where it's being used as well as how helpful.
<Mike_Elledge> ac: My suggestion if task basis, then knock of pts that are a barrier.
<Mike_Elledge> j: Additive or subtractive system. Subtractive requires rebalancing whole system. If additive just add to total.
<Mike_Elledge> ac: Will consider.
<Mike_Elledge> j: If have better idea, let's look at it.
<Mike_Elledge> j: Don't expect answers here.
<Mike_Elledge> d: First draft thoughts. A lot to discuss. Stumbled over: we use a ratig system in German test, page-based, quantitative and qualitative both.
<Mike_Elledge> d: Teaser image may get fewer points--subtractive. Both include quant as well as qualitative. Like heading structure workable, but not optimum, have something between pass and fail.
<Mike_Elledge> d: This is a different system. Pts for lots of tests, more pts=more tests. Problem. Want to measure quality of authored page.
<jon_avila> I know people will ask -- how many points to I need to get to be ADA conformant.
<Mike_Elledge> d: How we get to evaluating page not as important as result for end-user.
<Mike_Elledge> d: Adding pts for certain tests doesn't give fair assessment of quality of page.
<Mike_Elledge> sl: Agree that too complicated to figure out here, tests are illustrative of your comment. Test that validates for user should be awarded.
<Mike_Elledge> sl: Have to see how relates to pt system--does it reflect what user must do. Is this a complete failure, or reasonable that someone could do, or no on will have problem doing this. Will affect pts, but gets ocmplicated.
<Mike_Elledge> ac: Next step for ppl to try to digest, add comments to doc or email to silver list. One or the other.
<Mike_Elledge> awk: Comments to draft doc. To what extent peformance with Silver is going to be accessible. Perfect, or that much closer to perfect. Ppl think 2.0 represnets perfection, incorectly.
<Mike_Elledge> awk: Wonder if that is a problem here.
<Mike_Elledge> sl: Have conformance line up with user experience is our goal. Won't be perfect, but tyring to address wishy-washi-ness.
<Mike_Elledge> sl: So better reflects user experience.
<Mike_Elledge> sa: Wondering if two releated questions: 1) Conformnce with spec, testing and verifying vs. 2) how well doing overall, how accessible is your website.
<Mike_Elledge> s: Similar, based on calculated test. By splitting elements, will it be easier. Barrier walk-through method. How each barrier affects user.
<Mike_Elledge> s: have to run through each page, full test. Then id for each occurence how being met. Quite a complex task. See going in that direction here.
<JakeAbma> +1 to Shadi, he took my words 1-on-1
<Mike_Elledge> s: Should we look at that again? Spec vs. how you conform.
<Mike_Elledge> j: Interesting idea. Will ahve to think about that. Should talk so I can understand.
<Mike_Elledge> ac: Kathy has just joined. Can move on to mobile TF update.
<Mike_Elledge> sl: Thanks everyone for looking through it. Immensely helpful. Very complicated space and need help.
<Mike_Elledge> ac: Anyting else on Silver conformance.
<Mike_Elledge> ac: Kathy and Kim update on mobile.
<Mike_Elledge> kathy: PUt google doc into irc. Summarizing our feedback. All work done previously and id anything that didn't get into 2.1
<Mike_Elledge> kathy: and consider for 2.2 release or for silver. Spreadsheet in irc has first tab of proposals, sc want to consider for 2.2, then items also for Silver
<Mike_Elledge> kathy: may be changes to techniques, other items to consider, notes as well as draft proposals, in last column G.
<Mike_Elledge> kathy: Can go through this, will be meeting with low vision tf, to look at potential collaborative items.
<Mike_Elledge> ac: Quite a few. Have you thought about user impact, how close they got last time, something that was discussed, in terms of ease to add to 2.1.
<Mike_Elledge> kathy: some just adding technique to existing SC. when looking at some, some will be challenges as in 2.1, but worth talking about in larger group.
<Mike_Elledge> kathy: minimum number of pixes to achieve target. in 2.1 target size lots of challenges. tried to look from a different approach, user needs, to get in 2.1, touch screens and mobile format.
<Mike_Elledge> ac: seems like some for a 2.2.
<Mike_Elledge> kathy: yes, some for silver as well. silver are in silver column bec 2.0/2.1 would be challenging to add.
<Mike_Elledge> ac: next steps: overlap with low vision, then coordinate how could work in 2.2, list of things taht are good candidates.
<alastairc> q/
<Mike_Elledge> ac: questions, comments on mobile SC candiates?
<Mike_Elledge> mg: don't have document in front of me, but look at speech?
<Mike_Elledge> kathy: Kim Patch for some items. Challenge want could we get into 2.2 that wouldn't have same issues with geting into 2.1.
<Mike_Elledge> kathy: couldn't figure out how to do.
<Mike_Elledge> mg: talking about two-way speech interactions with a device.
<Mike_Elledge> ac: Need to defien web content for that.
<Mike_Elledge> R: Intent to go to coga or silver?
<Mike_Elledge> ac: At least one, possibly more for coga, but lots to do in design...
<Mike_Elledge> gs: Not sure what name is, but design guide, focus in coga on how to make significant impact sooner. Curren structure 2.1/2.2 not so conducive. So focused on Silver.
<Mike_Elledge> ac: Can go thru previous docs. Content (david mcd), definitely get more ppl looking into it in design guide. A set of techniques that don't fit WCAG, but more general, design oriented. Spacing and layouts.
<stevelee_> https://w3c.github.io/coga/design/
<Mike_Elledge> ac: are things to look at for inspiration, but didn't find many that fit 2.x model.
<Mike_Elledge> ac: anyting else on mobile? Look spreadsheet, add thoughts.
<Mike_Elledge> kathy: Ppl can put comments into doc or set up a survey if preferable.
<Mike_Elledge> ac: Will take up with andrew.
<Mike_Elledge> ac: tried to change link...
<Mike_Elledge> ac: had discussion before break, updated doc, confused people. Crux about req for representing states in controls.
<Mike_Elledge> ac: definition incl hover, selected, etc. if looking at link trying to avoid contrast req for visited vs unvisited since too many states to define. So how to addres check in checkbox.
<alastairc> https://cdn.staticaly.com/gh/w3c/wcag/non-text-contrast-updates/understanding/21/non-text-contrast.html
<Mike_Elledge> ac: Lots of discussion. moved to a different html service. as author would be happy if could address check/uncheck without addressng visited/unvisitd.
<Mike_Elledge> ac: How would we differentitate with same SC text.
<Mike_Elledge> detlev: AC brought up diff betw states. Clear diff that visited and active as interactional states, user is looking at content without doing something. Checked is conseuence of user action.
<alastairc> q/
<Mike_Elledge> detlev: Functional vs. transient state.
<Mike_Elledge> detlev: Quite different and need to differentiate.
<Mike_Elledge> ac: Would agree, struggling hwo we distinguish that with current SC text. Blanket def of states.
<Mike_Elledge> detlev: Perhaps another addition to distinguish between them. Could be a requirement for just
<Mike_Elledge> ac: agree, thought we had gotten there with focus visible
<Mike_Elledge> ac: Andrew was thinking of changing the text...
<jon_avila> I agree with AWK. We can't gloss over state requirements.
<Mike_Elledge> awk: I agree that focus is a state to be concerned about. Don't see how we ignore other states. Things like check w/in checkbox needs to be defined.
<alastairc> Checkbox example that shows problem with adjacent colors: https://raw.githubusercontent.com/Clarkdale/modern-radio-buttons/HEAD/images/Horizontal.png?raw=true
<Mike_Elledge> awk: Wrt links, hover or focus, covered by 1.5.1 (?) for text, would need to meet color contrast we have here. Otherwise covered by other criteria.
<Mike_Elledge> ac: Don't want to ignore other states either. One idea: visited links shouldn't lose contrast. Adjacent colors as criteria makes it difficult.
<Mike_Elledge> awk: New text was confusing, tried to clarify, but brought up differences.
<Mike_Elledge> gs: Adjacent colors is in current moment. Would be awesome if could do all states against all otehrs. That's why adjacent colors is in there.
<AWK> +1 to glenda
<Mike_Elledge> gs: If determined by user agent and not author. Have to see checkbox, and know if it is checked or not.
<jon_avila> Agree with Glenda that visited and non-visited are not adjacent so not covered. So only the visited and non-visited states as they stand on their own are covered.
<Mike_Elledge> ac: Problem is looking across states. RAdio buttons, where selected state doesn't have adjacent colors apart from itself.
<laura> +1 to glenda
<gowerm> Yes, I think you can use graphical object wording
<Mike_Elledge> ac: Maybe combine with graphical objects? Changes in form, arrows on navigation that change, graphical within the component.
<jon_avila> I get a 2.5:1 on Alastair's gray against white.
<alastairc> Jon - ok, bad contrast, but imagine that was contrasting, it has no adjacent.
<Mike_Elledge> gs: If a line around the hit area has to be seen. If not, then don't require that it meet criteria. Equal for both low vision and full vision ppl.
<Mike_Elledge> ac: I thought we'd dropped line, so wouldn't punish someone who use it.
<alastairc> Star examples: https://user-images.githubusercontent.com/216630/50792428-e06e7e00-12bc-11e9-8d2c-a2dbb56ebe9b.png
<Mike_Elledge> gs: No border around radio button, so okay.
<Mike_Elledge> ac: Stars examples. With, without greys in dark blocks. Yellow and white, should fail, but has adjacent colors.
<Mike_Elledge> gs: A color only issue!
<jon_avila> why is that a color alone issue?
<Mike_Elledge> awk: Would fail first two.
<Mike_Elledge> gs: Equally unusable for all.
<Mike_Elledge> ja: Wouldn't test for color would be greyscale test. Not really a color issue, just complicates things.
<Mike_Elledge> gs: Color alone. Not adjacent.
<Mike_Elledge> ja: Why is it color?
<Mike_Elledge> gs: The way we look at normative use of color not only way of conveying information. Can see the color so yellow and grey mean different things.
<Mike_Elledge> gs: Fields in grey pass, black fail.
<Mike_Elledge> ac: Reasonable proposal: Not a requirement that color changes, but where graphical objects are included (check, dropdown in nav) should have contrast.
<Mike_Elledge> ac: "For controls that just cange color (like links visited or hover) not req'd to h ave contrast with themselves, for controls that use grahical objects (check mark, check box or selected indicator--radio button, star) can use contrast as method of showing status change.
<Mike_Elledge> ac: where use graphic object to show status should have contrast.
<Mike_Elledge> awk: For white that turns blue on selection
<Mike_Elledge> ac: Doesnt fit graphical objects.
<Mike_Elledge> awk: Graphical object hs to be more intereting than rectangle.
<Mike_Elledge> gs: Somehting other htan html.
<Mike_Elledge> kh: Not necessarily..
<jon_avila> Here is a link to the stars in grayscale https://labs.levelaccess.com/images/3/35/Gray_stars.png
<Mike_Elledge> mg: Have language somewhere that accepts visited and non-visited color differntiation. Know that there's underline, but also visited vs non-visited.
<Mike_Elledge> mg: in my mind always clear division between non-text contrast, selection of star is whether color to indicate star has sufficient contrast.
<jon_avila> In the yellow stars example in grayscale you can see it's not the yellow but the lightness that matters
<Mike_Elledge> mg: for 1.4.11 concerened with white contrast w/ outline of star, and when star appears if shaded interior has sufficient color contrast.
<Mike_Elledge> mg: Yellow doesnt' have to be contrast when not selected.
<Mike_Elledge> mg: Dont differentiate contrast between states (like glenda said).
<Mike_Elledge> ac: Does it handle checkboxes.
<Mike_Elledge> mg: Graphcial object, check or no check. Can have cake and eat it too, also for radio buttons.
<Mike_Elledge> gs: Hae to be able to see checks.
<Detlev> That's why the check itself has to meet 3:1
<Detlev> scribe: Detlev
<Mike_Elledge> ac: Will go back to understandng document and see...
Jon: grey-scale stars - it's not a hue issue, it is a contrast issue
<AllanJ> https://labs.levelaccess.com/images/3/35/Gray_stars.png
Glenda: How would you have called this failure prior to 1.4.11?
Jon: It would not have failed - they are different in greyscale
Glenda: if you made stars green and red for on and off?
AC: With contrast there is another difference apart from hue
goverm: (Quoting SC for color?)
-3:1 when color alone is used
... conversion to grey scale can help to see if there is enough
contrast
AC: Does not impact where we go with 1.4.11 Understanding doc
<alastairc> https://raw.githubusercontent.com/Clarkdale/modern-radio-buttons/HEAD/images/Horizontal.png?raw=true
AC: Coverage lacking for radio button example (where circle is filled - due to lack of adjacent color)
AWK: It has an adjacent color - solid circle against bg
AC: sold!
Jon: the problem would be different shades of grey inside circle
AC: followed the principle of
looking at contrast where two areas not contrasting make up one
area, essentially
... still unresolved in that respect - will take what was said
today to update the Understanding text once more
AC: several Techniques mention
the AccName computation, now there is an official
recommendation
... no objections in CfC
... any objections now?
RESOLUTION: CfC accepted without objection, publish PR 555
AC: Was looked at in previous meeting
<alastairc> https://cdn.staticaly.com/gh/w3c/wcag/tech-reduce-motion/techniques/css/reduce-motion-query.html
<alastairc> Example: https://cdn.staticaly.com/gh/w3c/wcag/tech-reduce-motion/working-examples/css-reduced-motion-query/index.html
AC: Example used colour change
for reduced moton, which wasn't a good example - now the button
shakes
... so if you check reduced motion it will stop
... any questions or comments?
AWK: This is good - check number
two should be separate (essential) this is minor
... statement about understanding do should be moved into
description
<AWK> Change check to to become: "check if the motion is not essential", check 3 is "Check that the element does not move", and results are "checks 2 and 3 are true"
<Ryladog> +1
AC: Any other issues? Acept with changes?
<laura> +1
<MarcJohlic> +1
<Rachael> +1
<AllanJ> +1
+1
<AWK> +1 to accepted as amended
RESOLUTION: Accept as amended
... Accept PR 556
<alastairc> https://github.com/w3c/wcag/issues/352#issuecomment-452325804
<jon_avila> please don't add spaces into a phone number
<jon_avila> you will mess up braille!
AC: old issue 352 - does X in a control (for closing a dialog) count as text? Another scenario is adding square brackets - another adding spaces or full stops to improve pronounciation of phone numbers
goverm: colleague has done a lot
of work on this, also regarding automated testing
... differences between screen recognition and screen reader
output
... something like Search... differs regarding implementation
via three dots or elipsis
... dashes in phone number
... computation of accName should enter the understanding doc,
emphasise hierarchical nature of the algorithm
... grouping stuff not part part of accname
... telephone number may be read out three times
... recommendation that label comes first - group name may be
read out first
... understanding text should go into more details on resonable
adaptations
... it is not always obvious what the label is
... will send out a post about that to the group
AC: not going to resolve this now
<alastairc> Detlev: Could you adjust the understanding doc?
Detlev: Mike would you flesh out the Understanding doc?
goverm: yes get comments first from group, then happy to amend the Undersatanding doc
AC: good to see so much research
in this
... Any other business?
<alastairc> https://github.com/w3c/wcag/pull/576
AC: Another Technique by Rachael on boudary contrast - please comment
<Mike_Elledge> bye all
<laura> bye.
trackbot end meeting
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 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/1.3.11 (?)/1.4.11/ Default Present: KimD, Mike_Elledge, alastairc, AllanJ, jeanne, AWK, Lauriat, shadi, Detlev, kirkwood, Glenda, MichaelC, MarcJohlic, Rachael, Laura, stevelee_, JakeAbma, Katie_Haritos-Shea, Kathy, gowerm Present: KimD Mike_Elledge alastairc AllanJ jeanne AWK Lauriat shadi Detlev kirkwood Glenda MichaelC MarcJohlic Rachael Laura stevelee_ JakeAbma Katie_Haritos-Shea Kathy gowerm Found Scribe: Mike Elledge Found Scribe: Detlev Inferring ScribeNick: Detlev Scribes: Mike Elledge, Detlev Found Date: 08 Jan 2019 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.)[End of scribe.perl diagnostic output]
