<JF> scribe: JF
AWK: CfC that covers this, but does not seem like this will pass
Concerned what will happen with theis SC
is there something here we can address?
before we go to CR, we must address *all* comments
<AWK_> https://github.com/w3c/wcag21/pull/673
issue related to definition of target size - there is a PR now that addresses both issues
AWK: there seems to be a lot of varied opinion/discussion here
what to do" try to hammer this out, or walk away...?
<jallan> proposal:
<jallan> Equivalent - The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
<jallan> Inline- The target is in a sentence or block of text;
<jallan> User Agent Control - The size of the target is determined by the user agent and is not modified by the author.
<jallan> Essential- A particular presentation of the target is essential to the information being conveyed;
Detlev: want to point out a new proposal that Kathy pointed out
relates to issue Alex noted on previous call - re: spacing
<AWK_> Kathy's proposal:
<AWK_> The size of the target for pointer inputs is at least 44 by 44 CSS pixels or is at least 26 by 26 CSS pixels with 8 CSS pixels spacing between targets except when: Equivalent - The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels; Inline- The target is in a sentence or block of text; User Agent Control - The size of the target is determined by the user agent and is not modified by the author. Essential
<AWK_> A particular presentation of the target is essential to the information being conveyed;
Detlev: want to be sure everyone is aware of this, so we can review and discuss
but note that we may not have enough time now to do so
AWK: added Kathy's proposal
... we can continue to discuss, but have concerns about
time
<Detlev> there is also Jake's comment on a mismatch between 26 + 8 and 44x44
AWK: we have roughly until next Tuesday, and we need to process all comments by Tuesday or Wenesday next week
JW: want to note Mark H's comments, and also to note that the input from MSFT is significant, we should perhaps be looking at "mechansim is available" language here
AWK: we went from 44 X 22, and now we have a new proposal of 26 with 8px spacing - will anyone have problems with that
Detlev: what is unclear is the point that Jake raised... the issue of lists, pulldown menus, etc. - will they be covered/extended to that?
would they be exempt? It seems unclear to me
Detlev: fear we are running out of time
AWK: the Action that seems to be emerging is to get a link to the MSFT research taht may help us reach a quick conclusion
but share Detlev's concern around time (and lack thereof)
KD: there are also concerns about blocks of text... concerned about unintended consequences of layout and design (horizontal and vertical spacing)
may actually have an impact on readability...
KD: concerned that we may be rushing this too quickly
AWK: any further thoughts?
JW: curious to know what the strategy is overall? We have a number of difficult SC that still need to be resolved.
Do we publish what we have, and then keep working on problem issues?
AWK: relates to jason's point, and looking at the schedule
<AWK_> CR: January 23, per schedule
we have a tight schedule now. According to the plan...
<AWK_> Monday, January 15, note to chairs list at W3C that we intend to go to CR soon
<AWK_> Tuesday or Wednesday, January 16-17, start CFC where the WG approves going to CR.
<AWK_> comments needs to be addressed
<AWK_> Transition request when CFC passes
AWK: so, not a lot of time. Do we want a spec that has *all* SC, a spec that is *on time*, or something different?
Quality, on-time, functional - we need to pick 2
on-time isn't really open to negociate
1 day? maybe 1 month, no way
CR cannot drag on
AWK: focus is on getting it out on time, and that the spec is "good"
if we cannot address all comments, or come to consensus on changes, we need to take hard decisions: marking items "At Risk"
other option is to remove those SC we cannot address
not optimum, but something we all knew was going to happen
AWK: we are starting to get a sense of what we can and cannot do in our rigorous time-schedule
recognize contributions from all, and still not too late to jump in
We need to be wrapped up no later than next Tuesday - we need 48 hours for the CfC
KD: need a bit of context. If we
drop something out at this time, what happens next? Work on a
2.2, or will outstanding items go directly to Silver?
... presume that we can continue to work on items, even if they
don't make 2.1
AWK: correct. The main issue is that there is still a lot of work to get 2.1 out the door, so there is that
we cannot publish a WD of 2.2 while 2.1 is still in transit
but we can continue to keep working - i.e. additional research and discussion
<jallan> scribe: jallan
JF: silver TF meeting at CSUN. Silver is not the next step. Silver will be different from WCAG. I think 2.2 is a more likely next step
<scribe> scribe: jf
LS: perhaps with 2.2 we can revisit "extensions", and have no real expectation that things will change in 2.2
wondering if we can revisit that
AWK: is a possibility, somethig
we can discuss but today isn't likely the right time - no
decision there today
... processing all comments between now and Tuesday is
critical
while editors do the "detail" work
if we don't resolve all comments, we need to make hard decisions
AWK: survey about reflow
6 people have reviewed the response and believe it is fine
seems that there was also some confusion on the part of the commentor
so response is that there are other techniques beyond what the commentor believed, but no need to meet PDF-UA to meet reflow success critera
AWK: any concerns to the
response? Survey seems unanimous, but...
... any objection to accepting as proposed?
[crickets]
RESOLUTION: accept response to Issue 589 as proposed
<jallan> scribe: jallan
awk: have ~13 issues related to
common controls
... straw poll, most thought it was not going to make it.
... not sure how it will make it ... too many issues.
... many issues not resolved. Not a AA
jf: sad at the state. Issues
raised are good and valid. want to salvage something at
AA
... can we split. to keep autofill as AA, and other parts
metadata, etc. as AAA.
... then we have something to build from.
... hope to force devs to build content. chicken and egg.
<gowerm> I agree inputs/autofill is the most viable
jf: autofill is good and
functional. AA would be good
... metadata will be hard.
<Lisa_> https://docs.google.com/document/d/1YiknHDDDdKBdwVTEpxwUpyCaQL_tnpp9CfDlFjCq16E/edit#
<scribe> scribe: jf
<scribe> scribe: allanj
ls: some sites created using metadata. DiagramCenter.org wants to make a site.
<Lisa_> Chrome extension http://accessibility.athena-ict.com/personlization.shtml Open source script (Ayelet) https://github.com/ayelet-seeman/coga.personalisation EA (slide wiki), MArk (ATOS), https://a11y-resources.com/developer/coga-personalisation User Frist (five sites currently using it) hopefully diagram , autocorrect: Autocomplete https://jqueryui.com/autocomplete/, https://api.jqueryui.com/autocomplete/, W3Schools https://www.w3schools.com/tags/att_input_autocom
ls: TF has done lots of work. we have implementations. We created a tool. worked to remove At Risk label
awk: we don't remove At Risk label. miss-understanding
ls: thought we needed 2 different implementations in 4 different technologys with 4 websited
awk: at risk is a CR criteria.
depends on comments from CR. and all issues resolved. must
reach consensus by time line.
... 2 of the 4 AT RISK have been removed because of issues and
comments.
ls: confused. thought we are not yet in CR. labeled at risk because of technology support.
awk: must happen by tuesday.
Michael: at risk because no review in a working draft.
jf: kills me we are hitting a
wall.
... none of the examples are standardized, written down
somewhere
<Lisa_> https://w3c.github.io/personalization-semantics/content/index.html#destination-explanation
jf: think the implementations are
great. its a proof of concept
... semantics work is great, but not stable. Yet.
... great foundational stuff. still needs lots of work
... want to save something. like autocomplete. so we have
something documented.
ls: it is as stable as aria at same point in WCAG 2.0. you can't do many things without ARIA, that was not available at WCAG2.
<AndroUser> you can't even do Tab menus properly with ARIA
ls: personalization going to have an new draft out soon.
<marcjohlic> why is there no point at AAA???
ls: did not understand the process. frustrated.
<marcjohlic> You build on AAA for the next iteration
<marcjohlic> WCAG is moving much faster these days
<AndroUser> +1 to Marc
<marcjohlic> I disagree - it WILL promote the idea - get the ball rolling - and help individuals that could use this.
ls: AAA will not do anything. It won't help. Not worth investing more time on my part
<marcjohlic> Also being able to separate autofill / inputs will help individuals and get the ball rolling
<marcjohlic> It's a shame that individuals will lose out - and the ideas won't be surfaced because of this "all or nothing" stance.
ls: thought we met exit criteria. will be there in 2 weeks. pulling rug out from all people who have worked hard on this.
jf: opinion of ARIA in wcag
differ. we don't have the support. not happy about AAA either.
reality... best efforts... we don't have enough stable
implementations and standards.
... want to save something.
... perhaps Autofill at AA is a good thing.
alex: other ways than wcag to get
things done. these are good experimentation. would like to
explore to improve user experience.
... many issues suffer same fate as this. WCAG is not the only
answer. Need to explore more.
jason: +1 to Alex. other
collegues agree. strongly support evidence base
solutions.
... experiementation must take place first before we create a
standard. need to refine to scale implementations and
demonstration of effication
<Rachael> Scribe: Rachael
Lisa: Have been research projects. WACI project. A lot of what we have at AAA. Users liked it. Ran out of funding and no content. That experimentation has been done. Scripts weren't allowed in 1.0. ARIA moved forward because it helped industry include scripts. This situation is different.
<Zakim> AWK_, you wanted to discuss JF's autofill-focused approach at AA
There was more ability to push the corporations. This time we need to make it more accessible and its a problem.
AWK: Discussion about John's proposal of AA autofill proposal. What support and viability does that have?
Proposal is taking existing 1.3.4 and instead of embedding list of common purposes, the second half of which is input controls which is alinged with HTML5 autofill.
<JF> 20 input types
<Lisa_> 0
<JF> more of a shave than a haircut
This would cut it down to those autofill values. What do you all think about that approach?
JF: I just checked and it is 001-020. Currently 20 items.
<AWK_> https://www.w3.org/TR/html52/sec-forms.html#sec-autofill
JF: When you look at autofill. Look at Name, there is an overarching Name but more granular first name, last name, etc. There may be internationalization issues at the granular level so recommends using hihger level.
AlexWe now use working
scribe: working group specs.
<AWK_> https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill
JF: I believe that list is supported in the browsers. Pointing to the spec is a political decision.
Alex: I don't want to start the political debate. But if its going to work, we need to consider it.
AWK: The two lists seem to be in line at a glance.
JF: We have actual terms in the draft spec. When I look at the WHAT WG spec, they list the tokens. As part of understanding doc, we'd need to map the terms to the tokens.
<AndroUser> Alex raises good points
AWK: Does this seem like an approach that has immediately obvious flaws? If so, what needs to happen to make it work?
<Lisa_> I will be organizing a formal objection
<Detlev> So any author would need to implement the HTML5 field types OR fail WCAG?
<AndroUser> is Joshue108
AWK: It might be a simple language change in term of a link. Is there more to it?
Alex: Is this going to be a normative list?
AWK: If there are better ways to
do it, bring it up now.
... It addresses the concern that we are not building a spec,
but referencing one. Then in 2.2, we could point to the COGA
semantics if they are available.
JF: One way to resolve this is in WCAG 2.1, the list we present is what the inputs would be labeled. That addresses translations. Then we include a mapping table.
We need to provide both the label and token.
The token is what needs to be used in the code. When you have a field seeking a credit card number, no matter what the field is labeled it should say cc-number
AWK: Is that the way to do it? We'd have this table so someone in France or Japan would have a localized version of WCAG based on language. Is the html spec not localized?
<JF> Label: Numero de Carte de Credit, WHAT WG token: cc-number, W3C HTML5 token: cc-number
Or do we reference localized versions of the HTML spec?
JF: The tokens remain standardized. We just provide the common language table with various languages. Label commonly used, token you must use
AWK: What portion of that is normative?
JF: In our specification, the
list of label terms which will be somewhat subjective due to
translation issues.
... We specify which labels need tokens applied.
AWK: Html 5.2 on W3C site is what it is. If we point to that and specify the 20 values they need to use when conforming to this sucess criteria. Then non-normative document with mapping. Here's how these things map going forward.
gowerm: The success criteria should not point to an HMTL spec
AWK: Some of our commenters are asking for that.
<Zakim> gowerm, you wanted to say providing the normative labels seems problematic
gowerm: We need to state that where tech supports it, we provide the list of meanings. We don't worry about hte techniques. For example, if creating in html5, use the html5 list. If another technology, use the list for that.
AWK: That is a more technologically independent approach
gowerm: I don't think we need to include a list in the SC. Put that in the SC. We need to construct the wording so success/failure can be determined.
JF: So are you saying we wouldn't provide a normative list?
gowerm: I don't think we need to. I think we specify that you need to conform to the list.
JF: When we talk about autofill, we talk about a specific function. We need to clarify what our expectations. We aren't telling you how or which spec, but you need to achieve the success outcome but I think we still need a list that specifies the minimum expectations.
<gowerm> We simply say 'use an external list' for AAA. How is this different?
To not have a list in our spec, would be too loose from a testing perspective.
Alex: We need to know when testing where to stop.
<AndroUser> +1 to that
AWK: Mike does this approach make sense to you? And others?
<Lisa_> -1 to the whole thing
Should we invest any time in this?
gowerm: I'm not that happy with it but I can live with it. We need a list of values.
<Zakim> Greg, you wanted to say Mike Gower's approach seems appropriate. The requirement could be to support the mechanism provided by the technology being used. We could provide a minimum
Joshue108: It makes sense to me to take a stages approach and then build on it in 2.2.
<Greg> Mike Gower's approach seems appropriate. The requirement could be to support the mechanism provided by the technology being used. We could provide a minimum list, each being conditional upon its support by the technology. That list can then be larger than what's supported today.
<david-macdonald> I could live with a short list that has user agent support now.
Greg: It seems to me that Mike's approach is appropriate if we include a minimum. Then when technology updates, it would come into effect.
AWK: That seems like a possibility but we'll run into implementation challenges.
<Zakim> JF, you wanted to say that we'd probably need to change the SC name as well to "Common Inputs" (as opposed to "Common Controls"
<AWK_> AWK accepts JF's offer to help drafting language
<Aex> i suggest we change the SC title to autofill
<Aex> or autocomplete
JF: If we pursue this, and I am prepared to work on this, we need to change the name to common inputs. I think we can get this ready by the weekend. You need it by next week. I'd like to continue to pursue this. I think geting something AA is important. I'd rather a something than a nothing.
AWK: I think we need something by tomorrow morning at the latest if not today. Preferably today.
Lisa: I'm completely unprepared for this. I've been through notes and I'm not sure how we go here.
We put this in with the understanding that we'd remove this if the AT wasn't working by March. We only gave people a couple of weeks between getting this into a serious draft and taking it out. Its labeled at risk because of needing the AT. There hasn't been enough time.
<gowerm> In content implemented using markup languages, for each user input component that serves a purpose identified in the Common Purposes for User Inputs section, the meaning can be programmatically determined.
I think we've told a few groups to take a serious look at this and they are adding it to backlog. Then I have to reach out and tell them its out. They won't put AAA in backlog because it won't have content support. We would be killing this.
<JF> @gowerm - yes, something like that. May want to tweak it a tad more, but that's the general thrust
AWK: I think you are making a more pessimistic interpretation but I understand the frustration. When we put the SC in, it was recognizing we needed feedback and much of it was vastly negative. As written it won't make it.
<KimD> *Do we have time to put out a new SC? Is there time for comments, etc.?
<AWK_> not much, Kim
<AWK_> With this as retaining a portion of the existing 1.3.4 this is possible, but barely
Lisa: We've had some more and less formal committment. We've given them a date. How many people were unhappy and were they from the same organizations? I'm looking through issues and 2 people didn't like it. Is that enough?
AWK: I encourage you to review the email I sent early yesterday or the previous night wiht all the comments we had at that time.
<marcjohlic> AWK's note: https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JanMar/0207.html
<AndroUser> Thanks all
<AndroUser> Gotta drop
AWK: If you have time, please see that link and write a response. If not, keep up wiht emails.
<gowerm> scribe: gowerm
<AWK_> 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/that katie pointed out/that Kathy pointed out/ Succeeded: s/respons/response/ Succeeded: s/When I look at the WG spec/When I look at the WHAT WG spec/ Succeeded: s/say cc-num/say cc-number/ Succeeded: s/OK, well... I'm gonna dash then. Thanks and have a great day!// Default Present: AWK, Laura, MichaelC, jaalan, jallan, JF, SteveRepsher, KimD, jasonjgw, MikeGower, shadi, Aex, Detlev, Rachael, Mike_Pluke, Greg_Lowney, david-macdonald WARNING: Replacing previous Present list. (Old list: AWK, JakeAbma, Detlev, bruce_bailey, Laura, Greg_Lowney, Makoto, Katie_Haritos-Shea, jallan, Brooks, Alex, SteveRepsher, jasonjgw, Rachael, JF, Mike_Pluke, MikeGower) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK Present: AWK Laura MichaelC jallan JF SteveRepsher KimD jasonjgw MikeGower shadi Aex Detlev Rachael Mike_Pluke Greg_Lowney david-macdonald Found Scribe: JF Inferring ScribeNick: JF Found Scribe: jallan Inferring ScribeNick: jallan Found Scribe: jf Inferring ScribeNick: JF Found Scribe: jallan Inferring ScribeNick: jallan Found Scribe: jf Found Scribe: allanj Found Scribe: Rachael Inferring ScribeNick: Rachael Found Scribe: gowerm Scribes: JF, jallan, allanj, Rachael, gowerm ScribeNicks: JF, jallan, Rachael Found Date: 11 Jan 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.)[End of scribe.perl diagnostic output]