<david-macdonald> test

<Glenda> scribe: Glenda

<ChrisLoiselle> I am

<ChrisLoiselle> Not sure, Wilco was not on call

Supplementary document(s) survey: https://www.w3.org/2002/09/wbs/35422/WCAG21_supp/

<Detlev> You sound very muffled Jodh

<wayne> + 1

Joshue: asked the group if supplementary docs to document user needs that are not yet met in WCAG 2.1. Is it a good idea. Should we do it? And most people say yes.
... next question. one doc or many? Currently the favorite is option 2 (one large doc with info in one place)

JF: can live with option 2. Thought option 1 might be easier for release.

David: can absolutely live with option 2. I was thinking we could get Eric to do a filter so you could see just what you wanted to see.

Lisa: some situations may need to filter on pieces of coga, for example, some complex policy may need to be selective on coga, while an emergency alert should include all coga needs
... concerned if we blur the coga research needs with the well known coga users needs. May be too easy for people to just dismiss known coga user needs on crtiical things like emergency alerts.

MicahelC: concerned if we separate the docs, it will be harder for people to understand. This supplemental doc is not intended for policy yet.

Rachel: I prefer a single document with a filter.

Lisa: matrix of how ready some coga things may be for consideration in policy making. We could move faster with this supplemental doc, because it is not normative. And we could get closer and closer to something people can use, including for policy. Huge disservice to coummunity of we lump everything into one doc.

<lisa> note that they had not heard the issues yet

Joshue: majority prefer one doc. if we find it isn’t working as one doc, we could split it out.

James: what is the difference between this suppliemental doc?

Joshue: will not include any normative success criteria

<Ryladog> +1 to being able to change/update/improve supplementary Non-Normative support docs

Glenda agrees with Katie and adds her +1 to being able to change/update/improve supplementary Non-Normative support docs

James: AAA SC are better for policy makers, because you have to have normative

<Detlev> +1 to James

JF: value of getting research on low vision and coga published at the W3C is really important.
... also getting a list of things that need additional research (to inspire people who want to dive in and explore something that we need more data on)

Joshue: should the supplemental docs be normative or non-normative. 2 voted normative. 10 voted non-normative, 7 voted no preference or not sure.

<ChrisLoiselle> I had the same reasoning

Raquel and Chris voted normative because it could have value for policy makers.

Lisa: impossible to put these as AAA in WCAG, not enough time. We know they are important, but we don’t have enough time or SC managers. The research is published to show that these are needed. As long as we mark what is normative and what is not normative. I’m hesitatant to call it normative because it will slow down the approval process. But I suggest we start with non-normative in the 1st draft, but to add some normative sections in future relea[CUT]

appropriate.

Mike_Elledge: you shouldn’t have something as SC without examples of how to do it. I vote for it being instructional at this point.

<lisa> every singlal proposal has ways you can do it

<lisa> jason: judy said it can

<lisa> we need to look into it but apparently it is possible

<lisa> i might have suggested the wrong spec

Jason: resist the claim that you can put normative content in a working group note when it has not been through the normative review process. dangerous concept. I don’t think it is a good idea to do that.

James: If it is normative, we would have to recharter.

<JF> "A Working Group Note or Interest Group Note is published by a chartered Working Group or Interest Group to provide a stable reference for a useful document that is not intended to be a formal standard, or to document work that was abandoned without producing a Recommendation."

<JF> https://www.w3.org/2017/Process-20170301/#recs-and-notes

<AWK_> +AWK

<lisa> i object

Joshue: proposal “Group prefers having 1 supplimental document that is non-normative.”

Lisa: I object to this being 1 document.

Joshue: Lisa can you live with us starting with 1 document with flexibilty to change in the future.

<JF> +1 to MCooper

MichaelC: I don’t think we should allow editorial considerations to weigh in to this decision.

<KimDirks> +! to MC - I'd rather have it move forward and refine later as needed. It should be out there.

<Ryladog> +1 to getting it out there, determine format later

<AWK_> -1 to the idea that the needs of the other TF's are less than that of COGA. The other TF's have trimmed their proposals substantially.

MichaelC: we can revisit the supplemental doc structure if we see needs in the future.

<ChrisLoiselle> To Joshue's non-normative content : +1 to the non-normative question # 4 on survey after hearing discussion. Wasn't aware of the re-charter component.

Joshue: proposal “Group prefers having 1 supplimental document that is non-normative. with a recorded objection by Lisa (who is not comfortable with it being 1 document)

RESOLUTION: the working group has agreed to publishing supplemental guidance in 1 document that is non-normative

ACT TF Update

Target size discussion/legacy content and WCAG 2.1

<JF> @Detlev, thanks for the research and clarification

Detlev: the UK does not require the use of the latest standard, so we do not have to worry that WCAG 2.1 will instantly be a legal requirement in the UK. We can make old content meet WCAG 2.0 and new content meet WCAG 2.1.

jason: when we determine how hard it is to meet a proposed SC, we should be thinking about WCAG 2.1 applying to new content (not existing content).

<EA> Government requirements for some countries with regard to WCAG 2.0 https://www.powermapper.com/blog/government-accessibility-standards/

Katie: that is what new 508 standard does for legacy content does as well.

Lisa: we are not policy makers. we write standards on how to make content accessible. not our job to worry about requirement dates and legacy content, that is up to the policy makers.

<dboudreau> 44px seems awfully unreasonable to me as well

<Detlev> John, this was not about links but about controls like selectm checkboxes etc...

<david-macdonald> isn't inline links exempted

JF: I continue to struggle with a mandate that all links need to meet this target size. Concerned abuut the pushback from the community at large. I suggest we look at a surface area, not a mandated height and width.

<AWK_> +1 to David's point that inline links are currently exempted

<AWK_> Current issues listed at https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_status#Issue_60_-_Target_Size

Katie: let’s put it out there and see what the community at large has to say

<gowerm> Can a link be "an unstyled native control"?

Kathy: let’s put it out there, and get user feedback. Publish it with an editor’s note.

<AWK_> "Unstyled native user interface control"?

Alex: there is cost to putting a lot of things out there that are not solid.

<JF> +1 to Alex I won't block advances here, but remains sceptical and concerned

<Detlev> I thik the text on the survey doesn't yet reflect the latest version of target size

David: there is an exception for inline links. People’s concerns have been considered. Got good feedback from a recent presentation to people outside W3C.

<AWK_> What is needed to be changed, Detlev?

Target Size: https://www.w3.org/2002/09/wbs/35422/SCreview_May_17/#wbsq4

<lisa> note josh i had aranged to not be avilible this thrsday

<Joshue108> np Lisa

<lisa> (as agreed on a call with michael and andrew last week)

Kathy: added exception for targets in a block of text, including links, buttons, and other things. A block of text is already a WCAG definition in 2.0. We would use the same definition.

<Detlev> sorry AWK I see you have even put in my suggestion...

<gowerm> +1 to "form control"

Kathy: detlev also asked for an excpetion of an unstyled native form control, so that would deal with things like radio buttons unstyled.

Joshue: great Kathy, you’ve done a lot to address people’s concerns. Time to bring it to the group and ask “can you live with it”

<Detlev> agree to change "native control" to "native form control"

<AWK_> -1 to "form control" but "user interface component"

<AWK_> could be ok

Jason: worried about all the exceptions, some are more justifiable than others. Don’t want to exclude things that will really be a problem to users.

<Detlev> I think the In-Page exception can go because it seems covered by the inline exception

Kathy: trying to balance user needs, research, usability studies, with what is possible and reasonable. I’m also concerned with all the exceptions. So we would need to include a note about why all the exceptions are there (due to burdens on developers or legacy code).

<Zakim> AWK_, you wanted to suggest the removal of the Unstyled exception due to redundancy

AWK: in spirit of trying to reduce exceptoins, I think we can get rid of the unstyled user interface component . We can address this in a note.

Kathy: but this can be modified by css, so this is a difference type of exception

<gowerm> The target is unstyled and controlled by the user agent

<AWK_> User agent control: the appearance of the target is determined by the user agent and is not modified by the author.

<Detlev> +1

<Joshue108> +1

<gowerm> All the links exceptions can be removed then, I think

@awk - isn’t the definition for “user interface component” not “control”

Lisa: caution about not meeting user needs, if there is a way to solve this. The worst for the user is to object to letting any SC through.

<Joshue108> +1 to detlev

<AWK_> @glenda, yes, but that term gets removed from the exception as a result of this change

detlev: I like awk’s suggested text

gowerm: I think you can take inpage out.

<AWK_> Current version at this point: https://rawgit.com/w3c/wcag21/target-size_ISSUE-60/guidelines/sc/21/target-size.html

<gowerm> +1

<Ryladog> +1

<Detlev> +1

<Joshue108> +1

<AWK_> -1

<JF> 0

<david-macdonald> -1

0

<JakeAbma> 0

<dboudreau> 0

<alastairc> +1 suggest you keep a list of things taken out with reasons - otherwise they'll come back again.

<AWK_> (my -1 is close to 0)

<laura> 0

<steverep> +1

0 = neutral

<KimDirks> 0 - not sure about footnotes

<Rachael> 0

<Alex> 0 please explain it in note

<Makoto> 0

<Kathy> https://github.com/w3c/wcag21/issues/60

<Detlev> AA

<AWK_> The current version has both AA and AAA right now

<gowerm> Footnotes are in blocks of text

<AWK_> https://rawgit.com/w3c/wcag21/target-size_ISSUE-60/guidelines/sc/21/target-size.html

<Mike_Elledge> 0j

wayne: history has a lot of things that exclude people. What we need to do is start changing that by making things going forward accessible to all. We have a lot of conventions that exclude people. When the user agents are making some things inaccessible to people, we need to note that.

awk: we need to resolve if this is AA or AA A or both.

Joshue: it would be handier if it was just AA or AAA.

<Detlev> +1 to Kathy

<JF> split this into two

Kathy: the AAA was to have the AA version but with no exceptions

<JF> +1 to AWK for "seperatte thing"

split into two

<Detlev> yes split into two CfC

<steverep> q

<laura> +1 to spliting into 2 SCs.

<Wayne> +1 laura

<gowerm> +1

<Ryladog> +1 to 2 cfcs

<Kathy> +1 to having both AA and AAA but in separate SCs

<ChrisLoiselle> +1 to two

<JakeAbma> +1

Joshue: please put a +1 if you want to split this into two SC

+1

<Detlev> +1 for two versions: AAA Target size (no exceptions)

<dboudreau> +1

<Wayne> +1

<MelanieP> +1

<david-macdonald_> +1

<JF> +1

<AWK_> +1 to AA and AAA in draft

<Makoto> +1

<alastairc> +1 (I think they are two SCs, but need two CFCs?)

<Mike_Elledge> +1 for two versions

<Kathy> LEVEL AAA The size of the target is at least 44 by 44 CSS pixels for pointer inputs.

<jasonjgw> +1

<Rachael> +1

Any objection to putting this out as a CFC for Target Size being two separate SCs (one for AA and one for AAA)

RESOLUTION: Target Size proposal accepted

Plain Language: https://www.w3.org/2002/09/wbs/35422/plainLanguage-min-Issue30/

<lisa> Provide words, phrases or abbreviations that are the most-common form to refer to the concept in a public word frequency list for the identified context.

Lisa: I think what we need to do is agree on direction. I can’t tell from the list if this is a direction, that we need to work on the defined terms. Would people support this.

<KimDirks> Is the Rawgit right? (I need to *see* the final language.)

wayne: what always confuses me about plain language, what if you have something important, but you are in a content domain, where the language is specialized.

Lisa: we’ve put in the wording “public word frequency list for the identified context.” to handle the needs of specific domains

<Joshue_108> https://rawgit.com/w3c/wcag21/plain-language-minimum_ISSUE-30/guidelines/sc/21/plain-language-minimum.html

Lisa: we have a script that can run across sites to develop word frequency lists (for specific topic domains)

JF: unclear to me what I’m supposed to do with the list of words. what are we trying to achieve. Is it a glossary list, is it a thesaurus.

<KimDirks> Is the "common words" gone or not?

<alastairc> Presumably "Provide words or phrases from a public core vocabulary" should start "Use words..."?

Lisa: these are the words that are the most common words for this context. So instead of caling in “hypertext markup language” you refer to it as “html”. Test against your word list.

<KimDirks> I do not support "common words"

<gowerm> I have a suggestion

<gowerm> Sending to the group

<Wayne> Why does the dictionary have to be technology agnostic

<Rachael> scribe: Rachael

<EA> How does it work when people refer to the law for plain language? http://www.plainlanguage.gov/plLaw/index.cfm

Joshue: People are unsure of how thi swill be implemented.

<JF> Here is a public list: button label html wcag ws3c

Jason: Two problems that we have not addressed. Its entirely testable whether a word being used in content or not but difficult to determine which list. If you don't constrain the word list contents, then you can satisfy the requirement by generating a word list that meets your desired language. The second is the use of context. What are the restraints and criteria of adequacy for context and contents? Then how much will this help anyway?

<alastairc> +1 to Jason's comments, I'm struggling to see how the "common words" aspect would improve things in practice.

I think there are serious testability issues before we get to efficacy.

<KimDirks> So if 1500 common words for doctors is different than for financial professionals than for a psychology grad course -- I'm not sure it gives us anything - how does it help anyone?

Lisa: I would like EA to respond as she's the expert.

<dboudreau> Getting to a common agreement as to what those 1500 words is also puzzling to me.

I've tried to explain it so perhaps we should arrange a seperate call where the experts can discuss why this is so important.

<Wayne> +1 to off line call

<alastairc> It's a "a public word frequency list for the identified context.", but don't understand how that helps for niche topics.

Lisa: I thought I'd updated the inormation about how big the corpous has to be. How to build it . What are the contraints -- we can discuss this more if this is the right direction. How do we define context: its in the definition. We could make that definition clearer if you feel that is too weak. Neither of these are show stoppers but we have to first agree on the directoin.
... I suggest we have an extra call to discuss how we would do this.
... There are multiple techniques to address this.

<Mike_Elledge> Have to go...have same concerns as others. Thank you Lisa for more info and offer for call.

<laura> Updated SC text no longer has “1500”: https://rawgit.com/w3c/wcag21/plain-language-minimum_ISSUE-30/guidelines/sc/21/plain-language-minimum.html

<EA> Sorry I had my hand up and was going to support you Lisa. +1 to Lisa's suggestion

<lisa> do people like the direction of the common words :Provide words, phrases or abbreviations that are the most-common form to refer to the concept in a public word frequency list for the identified context.

Mike: We have an SC that says headers and labels descri topic or purpose. We have 3.3.2 that says you have to provide lables and instructions. So we have an SC that says you have to have labels and thy have to be dsecribe something. We do not have an SC that says the instructions have ot say sometihng useful. Would a solution be to mimic the headings SC for instructions.

<dboudreau> @lisa - I feel your idea has merit, but it’s implementation appears to be completely unmanageable & unrealistic in the wild… :/

Lisa: I'm not sure how that would address the user need.

Mike: It won't address everything but would fill a clear hole.

Lisa: They need to navigate to the content.

<dboudreau> Also, how will that list translate in different languages?

Lisa: People use termiology in labels nad buttons that can't be understood.

<EA> Yes this is a problem as Lisa has just said.

Mike: I regulalry fail people for bad labels but I can't for instructions.

<Detlev> @goverm: draft that?

<gowerm> Yes, I will draft.

<lisa> do people like the direction of the common words :Provide words, phrases or abbreviations that are the most-common form to refer to the concept in a public word frequency list for the identified context.

<Detlev> -1 due to unclear scope and applicability of the public word frequency list and doubt that it will cover different cases well

<alastairc> I think the public word frequency list is really problematic, either it is common & public in which case it can't apply to all content, or it is specific to a site and worthless for this SC.

John: The current wording doesn't say what to do with the words.

<Makoto> I'm still not sure if we could do this for Japanese language.

I think the word list is really difficult as well.

John: The wording needs to state that the words used must be taken from the list.

<dboudreau> @makoto - my point Makoto, how could we ever guarantee the internationalization of this idea?

<EA> Japanese can have its own list of characters representing their version of simple language as done with all AAC users and those who have cognitive difficulties

Lisa: The word frequency list is built using a tool across sites. The point is that it is a context wide list. What are common words used in programming?
... Then from there the words need to be the most common terms. That is how you use it.

<KimDirks> This seems like "best practice" non-normative idea. I could support that.

<alastairc> Building this word list sounds like it would take more time than doing an accessibility audit of the site...

John: Does every site need to create a word list?

<EA> John Rochford has been working on this and I think we need to have a discussion on how he managed this issue with Watson and IBM

Lisa: I've offered to create lists for 10 industries.

John: Will the list for a florist be the same for a coffee shop?

<alastairc> NB: There isn't an exception for names in the SC text yet.

Lisa: The lists should be the same unless you are getting into a really obscure topic.

<EA> You have a fringe vocabulary that are the specific names etc - Core vocabularies are the most frequently used words

<KimDirks> agree with Alastair - nothing in language exempts names of things...

John: Which word list is used to test and where do we get it from?

Lisa: If you are talking about conformance, the tester can select a word list.

* I do as well.

<Makoto> @EA - I've never seen the list for Japanese. I'd like to know who can create the list. How about Korean, Chinese and any other languages? That's my concern.

<KimDirks> Good point Makoto

Joshue: We will have to wrap this up. We can take it up again on Thursday. Chair hat off, I understand John's concerns.

<dboudreau> +1 to Makoto’s concern

Lisa: Can someone float an alternative?

<EA> Speech and Language therapists have to use core vocabularies in all their own languages on a regular basis - teachers, NLP, etc all have lists

AWK: These are at the techniques as well .

Joshue: I think Mike Gower was write that these may be addressed using techniques. Its not my job to say how to do that for a domain I'm not an expert in. I understand where you are coming from too.

<EA> Sorry I can not do Thursday but hope I can help later.

<JF> I am asking for a measurable Success Criteria, and the current wording doesn't provide this.

<EA> Can we not leave it a week?

<laura> How about hanging the techniques off of existing SCs?

<Makoto> +1 to JF

<KimDirks> If a "best practice" or has an exception for specialized professions/language - could possibly support.

Joshue: Lets give this a bit more time. Lisa is out so lets mark this for another week. Give people a chance to think about it.

<laura> bye.

<Joshue_108> 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/(Lisa's objection is to having a single document)//
Succeeded: s/RESOLUTION: the working group has agreed to publisihing supplemental  guidedance in 1 document that is non-normative/ RESOLUTION: the working group has agreed to publishing supplemental  guidance in 1 document that is non-normative/
Default Present: JF, allanj, ChrisLoiselle, Joshue108, Laura, JamesN, JakeAbma, Detlev, Kathy, David-MacDonald, Mike, Elledge, dboudreau, Glenda, MikeGower, Melanie_Philipp, Makoto, Wayne, jasonjgw, kirkwood_, KimDirks, 1, Katie_Haritos-Shea, alastairc, AWK, steverep, lisa
Present: JF allanj ChrisLoiselle Joshue108 Laura JamesN JakeAbma Detlev Kathy David-MacDonald Mike Elledge dboudreau Glenda MikeGower Melanie_Philipp Makoto Wayne lisa
Found Scribe: Glenda
Inferring ScribeNick: Glenda
Found Scribe: Rachael
Inferring ScribeNick: Rachael
Scribes: Glenda, Rachael
ScribeNicks: Glenda, Rachael
Found Date: 23 May 2017
Guessing minutes URL: http://www.w3.org/2017/05/23-ag-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.