<AWK> +AWK

<lisa> note the password is not the same tuesday!

<AWK> Scribe: Jan

scribes

<AWK> https://www.w3.org/WAI/GL/wiki/Scribe_List

<AWK> Sign up for a future call date

<David-MacDonald> what's pwd these days

<lisa> w3c

Personalization

<lisa> two sc

<lisa> https://github.com/w3c/wcag21/issues/6

<lisa> and

<lisa> at AAA https://github.com/w3c/wcag21/issues/309

<Detlev> is there a scribe already?

Andrew: Another meeting on personalization took place yesterday & 2 SCs were proposed from that meeting
... we will get the gist of that meeting describe to us today

Lisa: We may have to tweak the word "purpose" and use "function" instead because "purpose" may interfere with other SCs

<AWK> Can someone paste in the AA and AAA versions?

JF: The piece that is currently missing is not only telling them what something is, but what is the purpose - what are you supposed to do with it.

<David-MacDonald> 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)

JF: the idea of the AA is to use existing tools that we have write now to provide a description of what a person is supposed to do with conventional components - it's just about providing that information.
... at AAA is about using a fixed taxonomy; in AA, the description could just be written in prose, which is not ideal for machine checks, but it gives people a way to interact with the widget.

Alistair: I think this changes what it was trying to achieve - I thought it was trying to achieve cross-site compatibility, but now it looks like it's just trying to achieve in-site compatibility

<Detlev> What is the "personalisation" aspect at double AA then?

JF: At AA, we probably can't accomplish a cross-site compatibility because we don't have a fixed taxonomy, but we might be able to get there eventually; this is the way we introduced ARIA
... we are trying to set up a similar condition here - the net goal is to provide information on how to use conventional widgets

Lisa: I agree with Alistair that the more important issue is to provide a way to use this across sites, but that was not getting through, but with this alternative, we make it easier and more similar to what people are used to doing with pages across a given site. Longterm we would like for them to use the metadata, be we are not requiring it at AA at this time.
... what we were hoping is that over time, after taxonomies are more matured, then perhaps the current proposed AA would eventually be deprecated and the AAA would be move to AA
... this is a "can live with," there is a certain amount of compromise, but it's a huge win

David: I understand that you are trying to introduce SC that will act as a place holder for when the COGA stuff is ready to go.

JF: Not exactly

David: That is my understanding of it - I don't see much diffence between this and 3.3.2 - labels or instructions; I think this new proposal has a huge overlap with 3.3.2

<lisa> or metadata

JF: The difference here is the difference between "or" and "and." We want both - not either

David: We could probably do something with 3.3.2 - maybe we put this in for now and then roll them together after August. I just think that it's a lot of effort to learn a new SC without that much that is actually new.
... there are a lot of times when labels are explicit and easy for people to understand and if it's not clearn, then you provide instructions.

Jason: This proposal, along with this line, has potential, but there is lack of clarity at this point. I have addressed some of these on list, but I would also like to point out the ARIA work - shortcut attribute that points out that it doesn't specify what the actions or effects would be of using the shortcuts would be.
... the ability to specify with greater granularity and higher degree of machine readability is at least tentatively on the agenda of the ARIA working group for version 1.1.

<JF> Jason's example is illustrative of what we would like to see at AA

Jason: I think there's room for extention and we should be cognizant of this.

JF: Jason's example is exactly what we are talking about - that would be a success technique for the AA proposal - it would allow me to provide additional information.

<Zakim> alastairc, you wanted to suggest that we don't use the coga spec, but import the core items to WCAG material

JF: while the COGA semantics will be ideal for the future, the SC as written now just calls for extensible schemas that are available now, for example schema.org - we don't want to make it more narrow by specifying a specific taxonomy or schema, we want people to be able to use existing tools.
... The AA is different from AAA, but the AA sets up a condition to encourage people to go in the direction of the COGA semantics, but until they are more mature

Alistair: I believe the AA wording is pushing people in a different direction to than the AAA, so I would rather have a more defined AA and a more open AAA.

JF: Do we have agreement in the group of what we are trying to accomplish here?

<lisa> https://github.com/w3c/wcag21/issues/6

Andrew: Can someone please put the text of AA and AAA into IRC

<lisa> at AAA https://github.com/w3c/wcag21/issues/309

<JF> @(AA): In content implemented using markup languages, the purpose of conventional controls[1] can be consistently, programmatically determined across a set of web pages. @(AAA): In content implemented using markup languages, the purpose of conventional controls[1] can be consistently, programmatically determined and modified across a set of web pages through the use of metadata or semantics.

<lisa> In content implemented using markup languages, the function of conventional controls can be consistently, programmatically determined across a set of web pages. (AA)

<lisa> Note

<lisa> Conventional controls for form fields are: name (corresponds to both first and family), first name, family name, initial, phone (corresponds to a user phone number), cell phone, address 1, city, state, country, post code, phone, credit card, expiry, birth date, day, *month *year, expiry date, today's date, credit card code, date start, date end.

<lisa> Conventional controls for buttons or controls are: compose, delete, next, previous, submit, undo, cancel, buy, add label, move, view, save, send, received, sent, edit, reply, forward, my profile, upload, close, more, calendar, entry, expand, unexpanded, open, new, print, settings, mode, higher, lower.

<lisa> Conventional controls for links are: home, contact us, our phone, our email, site map, help, about us, terms, tools, comment, language, sign in, sign up, product, services, social, post, contactus, help, chat help,

Andrew: Are we defining "purpose?"

JF: People are struggling with that term, on list. The idea is that it is explaining to the user, how to interact. It is about helping someone know how to interact with a component.

Andrew: Does it give them hints about what will happen if they interact with this?

JF: Yes

<JF> Volume Slider: Role: Volume Property: Slider State: 50% (Purpose): Use this slider to make it louder or quieter

<alastairc> How will tooling happen if each site does it differently?

Lisa: The additional information this SC gives us is huge because as people begin to implement it and the tooling matures, then personalization will be begin to happen.

<JF> @alastair, it wont, not at AA, unless an org does taht too

<JF> so, for example, if the Beeb did this at AA, and used consistent terms, then a plugin *could* be created for all BBC sites

<JF> yes, sorry, I got those two transposed Andrew

Lisa: it opens the door to the use of metadata

<alastairc> tomorrow afternoon would be ok for me

Lisa: Perhaps if Alistair, Jason, JF, and Lisa get on a call to rework the wording, that might be the best way to resolve the concerns

Detlev: My main concern is that if this is at AA, if the typical way it to add contextual information with ARIA, that would be fine, but it does not seem to fit under the name of personalization - there is if you use metadata - otherwise, I think it would confuse people.

<gowerm> +1 to Detlev

<AWK> @@@ Issue - does the name fit for the AA SC?

<lisa> that could be good becuse it point to the prefered way and the explinations are trasitory conformnce

David: I actually support a AA SC - one camp seems to be saying "let's just really try to get a subset of COGA next year that can be supported and put that at AA," but the other camp is saying let's get something in now that can be used while the COGA semantics mature. The first option makes more sense to me.

<lisa> then we can mark it at risk

<Detlev> agree with Alastair's and David suggestion to focus on a small subset of coga semantics

JF: There's no guarantee that COGA semantics will be mature in the near future and so any SC that relies on those is a non-starter

<alastairc> Other idea: modularise "accessibility preferences", start with the ones needed here only, get that through asap.

JF: the idea of the current AA is to introduce the concept to the larger dev community that we have to do something more than name, role, and state ... we need to add purpose.
... if we can do that, we open the door to a fixed taxonomy in the future; the current SC proposal allows the use of ARIA or other current tools to provide the "purpose" through contextual information.

<alastairc> So every home link has to have a title attribute or aria-describedby?

<JF> good summary Andrew

Andrew: Does everyone agree with this general approach? It sort of hinges on wanting to do "something" with metadata, but certain subgroups don't believe that metadat can be used at AA, but could be used at AAA, so this proposal gives us the option of doing something at AA, while still offering the AAA metadata option.

<lisa> the best is the enamy of the good

<gowerm> Was there a question there?

<Detlev> no, because what is suggested at AA (unless you use coga-semantcis) has nothing to do with personalisation

Andrew: should we just stick with the required metadat at AAA, or should we continue with the proposal of AA and AAA options?

Jason: One of the ambiguity issue is the use of titles, labels, and other textual materials to provide information about a user interface component.

<AWK> Question: Do people support having an SC at AAA that requires metadata and do people support a non-metadata SC at AA that tries to provide some "hinting" for items on a page?

Jason: one suggestion earlier was to revise 3.3.2 so that it says labels AND instructions instead of labels OR instructions, but we would have to decide if we should have it at AA instead of A with the change to the word "and"

<Detlev> +1 to Jason

<alastairc> AWK - yes, but I more concerned with the AA SC, that's what will get the 'press'

<AWK> thanks alastair. Others?

<Alex> "Doing something" is not a valid reason to do anything. It comes down to cost benefit balance. This is too different and too new for me to tip my hand. But I am only inclined to agree if I can fully appreciate the benefit and the cost of implemeting this at scale. Not convinced yet.

<AWK> Alex, is that for AAA or AA or both

<Alex> AA

<David-MacDonald> 3.3.5 Help: Context-sensitive help is available. (Level AAA)

Lisa: I am wondering if you saw the note that listed the controls?
... you will have techniques in the understanding section
... To David and Alistair - we are not going to get it through if we try to press the metadata at AA

<David-MacDonald> could we move 3.3.5 to AA and add the metadata techniques

<gowerm> is anyone saying "I don't understand the benefit?" Has anyone said that?

Lisa: there seems to be a 3rd camp of people who don't understand the benefits - the benefit is that it will allow people who are currently outside of accessiblity to be included

<Alex> being "inclusive" is too high level of a "benefit"; you need to be far more specific

<alastairc> But this AA SC doesn't provide that benefit

<Alex> how will the AA provide symbols?

Lisa: we could even change the SC name to Personalization or Explanation if that resolves the concerns - there are millions of people who rely on symbols who cannot currently use web technology and this will allow them to get that access.

<alastairc> But how will a user-agent know what symbol to use when every site is different?

<Alex> but there's no metadata requirement in AA SC

Lisa: The AA will provide symbols, but if you use AAA techniques and use metadata, then the symbols can be added
... there are no metadata REQUIREMENT at AA, but it is a preferred technique

<AWK> Lisa, wrap up

<gowerm> And how does this benefit LV, which is what Wayne was asking for regarding personalization?

<alastairc> Lisa, could you link to an extension, does that exist now?

<lisa> andrew I thnk people need their questions answered

<lisa> that is a realy good thing to do on this call

<alastairc> gowerm to be fair the scope & SC have changed a lot.

<lisa> but some people have just joined

<lisa> and havnt seen the deom etc and then they dont know,

JF: Watching the IRC - both Jason and David have pointed to current SC 3.3.5 could be moved to AA / 3.3.2 changed to "and" - both are right, but it's more than the contextual help or instructions, it's about how to interact; at AA there is no expectation that metadata be used, but you can still provide information through other means. This sets the condition for growth in this area so that eventually AAA will move to AA.

<Detlev> If you really think this strategy will work - maybe its worth getting public comments on this

<lisa> https://github.com/ayelet-seeman/coga.personalisation is a lonk to the opensource implention

<AWK> I agree that people's questions need to be answered but I guarantee you that if you or anyone else talks non-stop as the questions roll in that people will tune out.

<David-MacDonald> 3.3.2 Labels or Instructions, 3.3.5 Help: Context-sensitive help is available, 3.2.4 Consistent Identification - All overlap

<JF> EXACTLY Jason, that is the idea

<lisa> old demo is at https://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html

<alastairc> Ah, the demo with scripts, sorry, I thought someone said browser extension.

Jason: I just heard from JF a proposal to change 3.3.5 and 3.3.2 - one way of going to this is add new SC that mirrow 3.3.2 and 3.3.5 and then after August those could be integrated back into those SCs as appropriate; another issue would be to provide more clarification about programmatic determination requirements and clarify what those are
... there are ambiguities with the definitions as they are proposed - what can be provided in natural language vs. machine language.

<lisa> andrew czn we set up anther wording call

Jason: I would suggest that we propose mirror SC to 3.3.2 and 3.3.5 and then look at combining them after August.

<JF> +1 David

<JF> we don't want to lose taht momentum

David: there is a lot of momentum behind this, which is good, but we don't have much time. Alistair, what are your thoughts?

Alistair: I am worried about having descriptions to every home link - that will not help website interfaces
... I am still fairly convinced that there's a nub of the metadata that we can get in - it seems easier than ARIA, in my view, and if it is then it's easier for browser tooling to deal with this.

David: That is my feeling too - I would not like to see us back off of the metadata issue and try to get something in at risk.

Andrew: I am hearing support for the AAA level, but the AA level may need to be morphed into a different form.
... I don't think we will get consensus on metadata at the AA level as a requirement.
... I agree that another call needs to be formed so that the wording can be tweaked. If you're interested in doing that, please put something in IRC

<JF> Monday is a problem for me Lisa

<AWK> Suggested times: A) 11am ET tomorrow or B) same time on Monday

Friday at 11:00 EST or the same time on Monday, the 24th at 11:00 EST

<alastairc> tomorrow afternoon (friday) best for me

<alastairc> a

<David-MacDonald> I could do Friday

<lisa> thank you !!!

Andrew: We will be meeting again on Tuesday

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/Topic: today's password for WebEx is W3C//
Default Present: AWK, KimD, JakeAbma, Laura, ChrisLoiselle, JF, steverep, jasonjgw, MikeGower, Greg_Lowney, Melanie_Philipp, Makoto, dboudreau, Detlev, wayne, WayneDick, chriscm, lisa, bruce_bailey, MichaelC, Rachael, kirkwood, marcjohlic, Pietro, jon_avila, alastairc, JMcSorley, David-MacDonald
Present: AWK KimD JakeAbma Laura ChrisLoiselle JF steverep jasonjgw MikeGower Greg_Lowney Melanie_Philipp Makoto dboudreau Detlev wayne WayneDick chriscm lisa
Found Scribe: Jan
Inferring ScribeNick: Jan
Found Date: 20 Jul 2017
Guessing minutes URL: http://www.w3.org/2017/07/20-ag-minutes.html
People with action items: