Accessibility Guidelines Working Group Teleconference

11 Jan 2018


AWK, Laura, MichaelC, jallan, JF, SteveRepsher, KimD, jasonjgw, MikeGower, shadi, Aex, Detlev, Rachael, Mike_Pluke, Greg_Lowney, david-macdonald
JF, jallan, allanj, Rachael, gowerm


<JF> scribe: JF

Target size survey: https://www.w3.org/2002/09/wbs/35422/resolving_target_size_issues/results

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

Issue 261

: Issue 261

<AWK_> https://github.com/w3c/wcag21/pull/673

issue related to definition of target size - there is a PR now that addresses both issues

Reflow survey: https://www.w3.org/2002/09/wbs/35422/resolving_issues_reflow/results

Target size - Issue 631

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?

Schedule to CR

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

Reflow survey: https://www.w3.org/2002/09/wbs/35422/resolving_issues_reflow/results

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?


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

Summary of Action Items

Summary of Resolutions

  1. accept response to Issue 589 as proposed
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/01/11 18:41:39 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]