<Detlev> I can scribe

<Detlev> scribe: Detlev

TPAC registration open. https://www.w3.org/2018/10/TPAC/Overview.html

AWK: You need to register for TPAC if you want to attend - costs may go up after end of July

AG meeting Mon 22 and Tues 23 October

AWK: TPAC is in Lyon

ACT TF, upcoming publication (intro by the TF).

AWK: Wilco will talk about ACT Task Force

<alastairc> URL: https://w3c.github.io/wcag-act/act-rules-format.html

Maryjo: A draft is ready for review, a survey is ready
... The last date for publishing is July 4 so we need to be quick

Alastair: A link to the ACT survey will be published this week

AWK: It would help for the WG the status / process of public working draft

Wilco: This is our wide review draft - it should be ready to go into CR
... THe biggest change in that draft is an update of the concept of rule groups, so you have your own rule entities
... atomic ules and composed rules (rule groups) - the latter are aggregations of atomic rules
... often you need a combination of things to conclude a failure - so for that you need composed rules
... lots of little changes
... Pleas help by reviewing the draft

AWK: Next is create survey then proceed to CFC so it can be published

Wilco: perfect

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

Silver requirements, survey at: https://www.w3.org/2002/09/wbs/35422/silver-requirements/results

AWK: There is a survey for the Silver requirements - Jeanne or Shawn?
... we should look at the draft
... Kim Dirks editorial comment
... Bruce - may not be complete enough to circulate for comments

Jeanne: thanks, will work on that

AWK: Reads Michael's comment (please refer to survey)

Michael: suggest to move problem statements out of requirements - should have an introductory sectino refering to problem statements

Bruce: agrees with Michael's observation

AWK: (paraphrasing Michael's comments)

<Wilco> +1

Michael: The two (WCAG 2.0 and Silver) should not be all too deliberably framed as an opposite

AWK: Michael - Silver comes across as discrediting earlier work
... (reading further comments in survey)

Jeanne: thinks comments are helpful, appreciates them - will take another pass through - would not want the requirement sto disparage WCAG 2

<Zakim> alastairc, you wanted to suggest that we need to incorporate 2.0 requriements, and prioritise them, and outline how to overcome contradictions.

Alastair: Statements come across as improvements over WCAG 2.0 if we take requirements for Silver on board it will become cleare how contradictions can be overcome - like measurability
... if there is some prioritisation, that might overcome contradictions

AWK: next part is about design principles ad requirements
... agrees that requirements in WCAG 2 are important and should not be left out
... feels like it feels like something that hasn't been done before - but that inclusion has been a principle also in WCAG before
... goo dthat people also see the continuity of the work
... (reading Kim Dirks comments)
... some comments had difficulties understanding what exactly would change mean

AWK (reading more comments)

Wilco: What's written is more on the level of goals than measurable requirements - same problem as WCAG had - talking about plain language but not be able to define it
... but good stuff there

<JF> +1 to Mike there

goverm: Will survey be open until tomorrow?

AWK: sure
... Don't put too much stock in last date of survey - may not close then
... further feedback appreciated

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

<Glenda> adding a link to a Plain Language checklist published by US.gov https://plainlanguage.gov/resources/checklists/web-checklist/

AWK: About non-text contrast exception, it's all around the focus on elements, outline of components
... If you haven't done the survey yet, please take a look and register your opinion
... one point of contention is unmodified content - does that aply to focus indication?
... wide view interpretation is that author has to ensure focus is fuly visible, follows contrast requirements;

<alastairc> 50:50

AWK: narrow view is that it is the user agent's responsibility
... pretty even split

Glenda: color contrast requires for- and background authors should be responsible as soon as they go away from the default
... can live with narrow interpreatation but prefers wide

AWK: (reads Matthew's comment)

Wilco: Wide interpretation makes less sense - things that are set by the user agent, untouched, should not be a violation - hesitant to require things that aren't explicitly stated in SCs

<Zakim> bruce_bailey, you wanted to agree with both Andrew and Glenda

Bruce: Agrees with both Wilco and Glenda - we need to revisit definitions - if you change bg color you take up responsibility for foreground color

Chuck: Needs clarification - question for Glenda - if you are responsible for contrast in all cases?

<JF> +1 to Chuck

Chuck: we should be responsible where we are making changes

Glenda: True - if you use defaults you are off the hook

Chuck: "If you touch it, you own it"
... If there is a contrast issue it may be down to developer OR to the UA to take care of the issue

JF: Most of the key point shave been said - agrees that if you touch styles then you own it to make sure contrast is good
... Some authors reset page bg color - but at that point they need to take care of foreground contrast as well

David: The wide interpreatation in fact change you have to take responsibility because there is practically no site that does not use styles

<Zakim> alastairc, you wanted to say focus indicator is in the middle, it isn't affected by foreground colour

Changes across sites and contents means that failures can then happen very easily

Alastair: Could go both both wide and narrow view - if focus indicator has not been touched then why own it - it is not the same as foreground color
... leans towards thinking it is a UA issue - if we require that everyone has to take care, there is less pressure on UA to change their default behaviour
... focus indication differs a lot across browsers

<Glenda> I can live with the narrow…and then we ask user agents to add oreo indicator

<alastairc> Presumably if you can't change the focus indicator colour, you then have limited choices on background colour.

<Glenda> I get that the normative lanugage has a “narrow” interpretation…and when a “narrow and valid” interpretation exists…(sigh)…I have to support that.

AWK: reads requirement in a way that the page background is not a component - in some techs you cannot change focus color, so we can't say you have to without leading to the position "we can't do anything about it". hard to see a path to unabiguousy say that you have to adjust focus color as well. If you do, you have to address the contrast ratio.
... Most professional sites change focus so are in scope

<Glenda> and pragmatically, I wanted to try and solve this in the “least effort” way…get user agents can solve soooo much

goverm: New conversation - we don't know yet how to expres the view we choose - forcing to change bg color is a heavy burden on developers
... if you override the UA focus many things can go wrong
... unclear how are we going to express that, in a failure technique - overriding focus is pretty clear, but that you own the problem as soon as you change bg color is more dificult

<Zakim> JF, you wanted to say that most professional sites today are also ensuring a background color declaration

<Glenda> I suggest add a failure technique (for when a developer changes color of focus indicator only). And then add a note in understanding (or even in the normative) that developer is only responsible for focus indicator if they change the focus indicator color

goverm: we have to develop nuanced guidance, but wouldn't want to go for failure techniques

<alastairc> focus indicator is not set from the foreground colour

<alastairc> is the right thing to over-ride the user-agent's interface?

JF: most authors make changes - most declare bg as white. If they change bg to blue, blus indiaction on Mac would be close to invisible. Do we wan tthat? That might encourage developers to do the wrong thing
... if you change on, you have to change both - no exculse for the content author

<Glenda> +1 to wilco (it is the normative text)

<Zakim> Glenda, you wanted to say “bp - do the right thing. but for compliance…keep in narrow and solve by asking user agents to have oreo focus indicators.

<KimD> +1 to Wilco. We have to be consistent with the language in the SC

Wilco: Shares John's concern, but this is the text in the SC that SC only applies if you leave defaults

if you change defaults, sorry

<Zakim> gowerm, you wanted to say if the user agent has a focus indicator that either has contrasting affordances or dynamic presentation, then the author does not need to tackle this

Glenda: can support narrow, but prefers wide

goverm: is only an issue in some UA, in others it is impossible to get wrong with different bg color

David: The SC language does not talk about focus indication - SC is not hard-baked to cover focus indication
... Not using a native component id different from not changing the focus

<Glenda> “where the appearance of the component is determined by the user agent and not modified by the author;”

<alastairc> Notes that if you have a dark coloured button on white background, if you enforce the focus indicator has contrast with the (dark) component, it will not contrast with the background...

David: how do people interpret "appearance of the component is not modified"?
... There is leverage to clarify it in the understanding doc

<JF> state: dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes

AWK: If default UA focus is not 3:1 would you need to touch it?

<Zakim> JF, you wanted to pose the question: is focus indication part of the component? If we change background color for text, we need to change the color of the text as well

AWK: only if you change its presentation

JF: focus indication is part of the component because the SC also talks about state

<Glenda> state

<Glenda> dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes

<Glenda> 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: Struggling to understand how you can exempt state - you need to do it for text, too
... The argumen tto separate focus from component is wrong

Component and its background are both part of the equation because that is what defines contrast

AWK: JF; is the argument that bg color is part of the component?

JF: yes

<Glenda> focus is a state. focus is not a component.

<alastairc> the visual info could be complely within the component, not the background of the component

AWK: but language only refers to components - the exception homes in on unmodified components (not bg colors)

<alastairc> inputs

<Wilco> JF: Outside of text can anyone give me a UI component that has natural styling from the browser?

JF: where are fore- and bg colors predetermined by user agents?

<Wilco> AWK: I don't think that's the point, and nobody is disagreeing that it is important. The argument is that the language doesn't support the interpretation

AWK: THis is not the point - argument is important - but language chosen does not support that interpretation

<Wilco> MG: This comes down to how you read this SC. If you think of a button like you think of text

<Glenda> where the appearance of the component OR STATE is determined by the user agent and not modified by the author;

<Wilco> ... For a link you get a dotted rectangle, the focus of links if you don't change it, you'd have a lot of people confused if you say it fails if you change the background of the page

goverm: Buttons and state of focus is different from text - text has dotted focus rect - if yu don't touch it most people woud disagree that it fails when bg color gets changed

<alastairc> This applies to links as well!

<Glenda> where the CONTRAST of the component OR STATE is determined by the user agent and not modified by the author;

<Wilco> ... When the state is done by the UA, I am concerned if you make the author responsible for the contrast if they change the background.

<Wilco> ... I want to make sure we end up with something that benefits the end user.

goverm: for a button, the state is defined by UA - when that state fails contrast against button or background is difficult to define clearly - we should be careful for mandating focus changes in situations where page bg changes

<alastairc> Firefox reverses the indictor on a dark background

JF: dotted rectangle is default in chrome, IE - so if I don't change it for white text on dark bg that would need to pass, that's wrong

goverm: that should pass, because it is not text contrast

Alastair: components includes text links

<Glenda> where the CONTRAST of the component OR STATE is determined by the user agent DEFAULT and not modified by the author;

SCRIBE??

Ta

<alastairc> scribe:wilco

<AWK> all glenda

JF: This SC applies to component states as well. White text on dark blue background is technically out of scope, the moment the link takes focus, if we don't modify it we'll have black on dark blue focus

GS: We can't solve all things at once. I can live with the narrow. A state is not a UI component, they are separate. The exception is only for the component
... In hindsight I would have rewritten.

DM: It didn't say the component and its background, it says the component. The language does not apply to the background.
... Could we jury rig it in the understanding document. It'd be difficult to get consensus.

<Zakim> JF, you wanted to ask a very scary question... should we seek to do a WCAG 2.1.1?

<Glenda> OREO focus indicators to the rescue. We really, really, really solve this when User Agents change the default focus indicator.

JF: Should we look to do an editorial change to this SC to clarify what we mean.

<gowerm> +1 to Glenda

JF: Everybody on the call understands the argument, and agrees with both sides.
... So do we do that editorial change?

-1

AWK: We'd have a very hard time getting doing that. I feel most people on the call agree about what the language says. Maybe we don't like, but it is what it says.
... There are also questions about if we could do the language that we'd want. My take, chair hat off, if we'd push for WCAG 2.2 in a reasonable time frame, we can fix problems and fill gaps at that time.

MC: I'd support that conclusion. Editor recommendation is possible but would require steps that can have it shut down. This is a bigger fix than anything else we've seen.
... We can explore it, but I'd recommend that we focus on 2.2 to address these issues.

DM: If we do go to 2.2, I would go we try to go in with less. It's easy to add things. We can't widen it down until Silver

JF: We can always go narrower, but it is hard to go wider. If we start wide.

GS: Disagree

AWK: You can have backward compatibility if you remove an exception
... I think we need some specific language. I hear a general, if pained, agreement that the narrow interpretation is the way to go for a defensible treatment of this. We need to get acceptance of changes in the understanding documents.

AC: I've started on changes for survey for next week.

Techniques, process and drafts.

AC: We were aiming for a rapid iterative update. If there is a new technique ready to go, it needs a home, ideally a Github pull request or a wiki page.
... If you put that up and announce it to the list, we would like for some number of people to give that a thumbs up
... If there are some people on the call now used to writing that material, we can get that ready for Friday, put it into the agenda for Tuesday
... If it clears the Tuesday meeting we can make it live soon after
... It'd be a case of check it over, get comments in on Tuesday. It'd a two stage process, announce to the list and have it reviewed by a few people. Than the general group reviews it. If it doesn't go live we can put it into draft again.
... Ideally we'd manage this with Github categorisation and labels.
... I know people have done some drafts already. How does that sound?

<alastairc> Wilco: In ACT we're doing new reules every month or so, and do this through githib issues rather than pull requests. People work on that proposal, when ready they put into pull request. If there are major concerns the pull request gets closed, and goes into an issue that the smaller group goes into.

AC: We have a first set of techniques, we have branches already.
... But you can't manage a branch. I'm worried it will get mixed with all other issues.

AWK: The question for the group is if they agree with a process that is designed to default to progress rather than stasis.
... If you can get 4 people to review a concept who are saying, this is a good idea, we like it. The idea would be as long as they agree, and they give enough time to the working group for review, unless there is something that comes up by the working group we'd publish it
... People may miss things, but we can just as easily fix it.

<Detlev> My questions: Necessary reannounce presence of Techniques already drafted? Any priorisation? How to deal with overlaps of technques

AWK: It would go forward unless someone actively raises an issue.

DF: I'm not sure if after all this I should reannounce the techniques I've already drafted, or if people will look at the documents and see what's already there.
... Is there a means by which we can prioritise techniques? Also some techniques seem to overlap. Some techniques seem redundant, but I'm not sure that they are.

<laura> Techniques Wiki page: https://www.w3.org/WAI/GL/wiki/Wcag21-techniques

AWK: If everyone will work on a technique, we may have more than people can reasonably review.
... We may need to have things in a queue. It may be 6, or some number we have to adjust as we move.

AC: It would help to send an e-mail to the list, one per technique. It is useful to use the wiki page so we can see what is there and we don't get overlap
... It's hard for me to prioritise techniques. Hopefully the taskforce can have things in mind

<alastairc> Wilco: Thought - auto-wcag is working on our first wcag 2.0 rule in flight, would it make sense for us to use these rather than failure techniques?

https://github.com/auto-wcag/auto-wcag/pull/146/files

WF: Propose using rules rather than work on new failure techniques

AC: There is a potential for overlap there. We should explore further. I would tend to prioritise positive techniques, how to pass things.

<Glenda> Hey Wilco - could it be “pass-rule”

DF: I want to get a sense of how we can deal with very similar techniques.

AC: We need to do a little gardening on the techniques pages. I think it is important to realise where the techniques came from. It's from the understanding document. They had examples.
... I think the best approach is to focus on ones that are needed - if you want to meet reflow, you need a technique for using flexbox or some other mechanism.

DM: In general, if something is more than a page we can split them.

DF: There might have been a reason for making them very atomic. There may be something in there unique to one technique that's different from a more general one. I would think we look at the ones that are most useful for passing content.

AC: Once we've got a few attached to each technique things will become clearer
... As we go through the proces of adding techniques it will be more obvious which will be useful.
... It is a matter of focusing on the ones that are needed to pass.

<alastairc> https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html

AC: In terms of our process, if Detlev sends this around to the list, a few people can review this. We have template guidelines and technique templates. I would suggest we watch out for accidently restating the criteria in a different way. This should include a test for that method

<Detlev> can do

AC: If it's a pull request, that is what we should focus on. Please include the rawgit link, people can preview it. The pull request becomes the place to comment on

<alastairc> Techniques to tackle: https://www.w3.org/WAI/GL/wiki/Wcag21-techniques#List_of_Techniques

AC: For next week we'll have the ACT document to review. If you have any other time to put towards WCAG I'd request people to tackle a technique.
... Have a look at the wiki page, put your name on it. If you finish one, send it to the list and we'll put it in the queue
... There is a technique template, and there should already be a branch with a blank template in it

<alastairc> trackbot, end meeting

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/you have to addres sthe/you have to address the/
Succeeded: s/wencourage/encourage/
Default Present: AWK, Chuck, alastairc, marcjohlic, KimD, Laura, JF, Detlev, bruce_bailey, Glenda, MichaelC, Wilco, kirkwood, Kathy, jallan, david-macdonald, gowerm
Present: AWK Chuck alastairc marcjohlic KimD Laura JF Detlev bruce_bailey Glenda MichaelC Wilco kirkwood Kathy jallan david-macdonald gowerm
Regrets: Joshue Rachael Katie Brooks GregLowney MikeE
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Found Scribe: wilco
Inferring ScribeNick: Wilco
Scribes: Detlev, wilco
ScribeNicks: Detlev, Wilco
Found Date: 19 Jun 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.)