<jallan> scribe: jallan

New chair announcement

awk: Welcome Alastair as the 3rd co-chair of AGWG

<laura> https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JanMar/1335.html

awk: congrats and condolences accepted

<Ryladog> Congrats!!

<kirkwood> Congratulations Alastair!!

<Brooks> Congrats, Alastair!

<marcjohlic> Congrats!!

<Joshue108> Felicitations!

<jeanne> Congrats! Thank you!

<Greg> Congrats!

ac: it will be a learning experience. bear with me

bb: all good?

<bruce_bailey> thank you

awk: plenty of work. all welcome

joc: delighted. lots of experience and skills.

<Joshue108> we are all just furniture at the end of the day :-)

dm: appreciate past work, thanks for stepping up.

close item 1

<MichaelC> agenda order 1, 2, 3, 4, 5, 6

Implementations (https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations)

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations

awk: status check, any problems

mc: want to talk about CR tool,

awk: same number of implementations as last week.

jf: need clarity on AutoComplete implementations
... looking at inputs with autocomplete. browsers have different levels of support.
... is autocomplete in DOM acceptable?

awk: no. image alternative text. if browser has alt in DOM but no AT reveals it, then it doesn't work. and vis-a-versa
... need it in the DOM, and browser reveals to user with UI - OK, or browser extension, or favelet,

mc: concur. only present in DOM was ruled out in 2.0

jf: native browser support only has been ruled out. will focus on helper tools

awk: looking for indication that SC is viable, and can be expanded on.

jf: looking to tools not necessarily sites.

<alastairc> Was just going to say - need both sites and tools, for 1.3.4 and several others.

mc: need sites with browser tools to support

jn: implementability vs implementation of tokens

awk: need to show implementation of all tokens we are requiring.

<bruce_bailey> +1

awk: would like to have functionality built into browsers without need for favelets.

<JF> @James, see: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations/JF/research

mj: have a site that fails. is it OK to call out a site that fails?

mc: in 2.0 self-submission. we asked permission to share sites. the point is to call out successes not failures. want to be careful

mj: at site, if rotate to landscape there is a dialog that says landscape is not supported.

awk: may be useful for a failure techniques. "nugget of failure", something that is persistent
... if on a real site... we hope it never changes.

mj: curious if anyone knows of an exception site that only works in one orientation. they are hard to find

ac: telling user to rotate back to orig orientation does not pass nor help user.
... google maps will reorient user

<kirkwood> google maps does rotate making text readable

<Glenda> +1 - check deposit photo is landscape required.

<Glenda> Note says: “NOTE

<Glenda> Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where binary display orientation is not applicable.”

mj: example of piano playing app works only in landscape.

awk: we say "orientation MAY be essential", how do we determine "essential"

brooks: need explanation on autocomplete implementation. input with appropriate token but not have the information filling in

<kirkwood> yes

jf: yes. in testing in windows. when you start to fill out, if token value is stored. the browser offers to complete it for you. user must activate the fill in. USER CHOICE
... one other test. input type of hidden, will it populate that information. a security issue. need to confirm personally

awk: back to implementations... lots of examples.
... hover an focus, label and name - both need examples
... label and name have examples

<alastairc> how about the adobe mega menu?

awk: hover and focus still need help.

dm: air canada - hover over prices. stuff popup

<alastairc> https://adobe-accessibility.github.io/Accessible-Mega-Menu/

<Joshue108> this is relevant..

ac: it is activated on hover and ESC will close it.

dm: air canada works better.

<david-macdonald> Air Canada changed, not on hover anymore

michael: some examples of login have timer countdown. but having trouble finding interruptions and don't fail timeouts
... looking for announcement that about to time out.

awk: anyone working on 2.2.6? created because of a gap. has it become too similar to 2.2.1

dm: need a warning that time will run out. should say duration of inactivity
... not at risk, so can't remove from draft without recycling process

awk: may need editorial change for clarity.

michael: will attempt new wording to meet criterial.

awk: please review 2.2.1 and 2.2.6. can you pass 2.2.1 yet fail 2.2.6. should be some differentiation between the two

<alastairc> Sorry to bail on my 1st meeting as co-chair, but have to go now, I'll be back on Thursday.

dm: 226 seems to be a bullet to 221. need to say the duration. everything else is the same.

<Joshue108> no worries

<Zakim> steverep_, you wanted to comment on keyboard accessibility of Adobe mega menu (if wanted)

sr: megamenu - keyboard needs work. need to passthrough screen reader keys for it to work.

awk: in application mode, doesn't that need to happen. haven't tested in several years.

sr: in browser mode, nothing happens when you pass over it.

awk: you can tab, to it, must hit enter to open.

sr: in FF can focus but noting happens.

awk: will have someone check it out.
... james mentioned oracle site one control may be an implementation

jn: hamburger icon with word menu at top of page may work for hover and focus

awk: adding implementations to hover
... any other suggestions or needing help.

Implementation testing tool

<MichaelC> WCAG CR evaluation tool

^^^ official link, most bugs fixed. should be able to do testing

mc: chairs to migrate info from wiki to tool. then folks can evaluate
... if training needed, we will set up.
... need implementation data in by end of March.
... USE THE TOOL
... timeline "end of March" working on specifics

mj: can I add directly to tool and note on wiki

<Joshue108> Sounds good Marc.

awk: that sounds fine for Marc only. initial testing would be great
... NOT everyone

mc: implementation will be tagged to mcooper email

awk: can you not put in someone elses email.

mc: tagged to users account. there are still bugs.

awk: chairs should be able to edit. Chairs will meet thursday morning

<Zakim> JF, you wanted to ask clarification: sites, or "pages"?

awk: chairs will be asking for testing ... soon. currently have 3 at AA, need 8 preferrable 16. have 2 at AAA need more. iterative process

<AWK> https://www.w3.org/TR/WCAG21/#exit-criteria

jf: 'sites' vs 'page', have a page with all autocomplete. the page is AAA. but site not

awk: 'site' is 5 page minimum. if 'app' with 5 screens, that should be adequate

<Alex> we are testing mobile apps?

could someone build a model 5 page site?

<Joshue108> @alex - yeah mobile is in scope

awk: could use sub-site, or subsection of site. or a demo site could be fine
... need something we can point to

<Glenda> We might be able to have some volunteers work on a previous OpenAIR site…like this one: http://gqh.edg.mybluehost.me/

<Alex> most mobile apps have one "page"

<Glenda> http://gqh.edg.mybluehost.me/sitemap

jk: don't need unique domain name. NYC gov, particular agency, would that work

awk: yes

gs: trying to find winners from AIR competition. the link above may work, or be cleaned up to meet criteria

<Alex> i don't think we can just make 5 pages of "hello world" web pages and call it a site, right?

awk: anything we can do to find sites is good. reminder to not call out failing sites. but may call out or ask to call out passing site.

<Joshue108> +1 to AWK, that will be interesting

awk: could talk to sites that almost pass about tweaks, but may get resistance.

mc: we have a month. may not have time for back and forth. don't worry about failing sites in testing tool

<Brooks> Scribe: Brooks

Issues

<AWK> https://github.com/w3c/wcag21/issues

awk: I haven't heard that anyone has responded to issues yet. Has anyone responded to any of the issues in the past week?

mg: I've responded to one, but will take another day to review before getting back on that - keyboard shortcuts clarification issue.

awk: Any other issue responses that are ready for working group to review?

dm: I've got one - There are two responses I've got prepared.

awk: This will require more work, so I'll add a label to the issue that says ready for working group review
... We don't have a lot of time, so if you are signed up to come up with a response, we need for you to come up with a response now.
... There are approximately 20 open items. We need for people to focus in on getting responses prepared.
... I expect that we will have a lot of comments coming in at the end of the available time for comments, so we need to clear the issues that are currently open.
... we have few comments that have come in with no one signed up to respond, so please sign up if you are able to respond. Please work on issues.

jf: I'll take the security question on 1.3.4

<JakeAbma> I'll take #772

awk: Rachael, would you please add to issues implementation page?

Techniques

ongoing discussion on 1.3.4

awk: John, you indicated you want talk about this. Was there a piece that goes beyond what we discussed earlier?

jf: Yes, what we set out to do with the original SC has shifted.
... There's been some discussion about renaming the SC.

<Joshue108> @rachael Thanks for those links - v. useful.

<JF> https://alastairc.ac/tmp/autocomplete.html

jf: Alastair has drafted some new Understanding content, which starts that process. He is suggesting a renaming of the SC to "Autocomplete"
... Autocomplete is leading the way to introducing personalization.
... Does this process allow us to rename the SC? And if so, do we want to choose a better name. Also, are we happy to Alastair's draft, or do we need more work on that?

mc: We can likely rename the title of SC, as it likely editorial - but need to talk with the director to confirm.

jf: We should rename, and it seems editorial to me.

<JF> ​Common Inputs Automated Inputs Metadata on Inputs (<< This introduces the concept of metadata, which may be a positive reinforcement)

awk: Is the proposal to rename to "Autocomplete"?

jf: other suggestions have come through the email list

katie: Probably need to change the number to 3.3 Input Assistance

<JF> https://a11y-resources.com/developer/adaptable-ui-personalisation#aui-field

jf: Right now we have a plugin that uses a different attribute, but it still uses the same tokens - easy win.
... working on getting a browser extension that would inject a user style sheet to work with autocomplete to inject user-specified icon
... we have moved away from the original intent of the user need. i think the decision needs to be made about what this about. This isn't the best way to go about adding metadata to address personalization need.
... s/jf /katie

<Joshue108> @johnF is that your website?

katie: this changed SC is not going to really be about personalization now.

<Glenda> +1 agree with what AWK is saying

awk: my take is that SC does start to help with personalization. what do others on the call think?

<Joshue108> +1 to this helping personalisation. Totes

<JF> @josh, no. It has been brought forward by the COGA TF, and I believe it belongs to Axios (sp?)

<Joshue108> @thanks John. interesting.

<marcjohlic> +1 to AWK - I think it's a way to start down the personalization path - will drive awareness

katie: last week, Lisa answered no to this question. In my mind, working on accessibility metadata and personalization is attaching something to each input is a developer-heavy proposition
... there are other ways to try to get accessibility data utilized. I'm not convinced that manually adding metadata to each and every input isn't the way to go.

<Joshue108> Actually a more incremental approach to Personalisation via the introduction of 1.3.4 could be a good thing so as not to ovewhelm devs.

awk: There's a fair bit of overlap between what we had before and what we have now in this SC. There is an onus that falls upon the developer on this, however.

katie: If this some kind of way to get semantic metadata in, it is very limited in its impact. The original intent has been convoluted into something that doesn't meet the overall problem that needs to be addressed.

<Zakim> gowerm, you wanted to say that the word "personalization" isn't in the SC language. The Understanding doc isn't normative and easily changed to make it more accurate.

awk: disagree that's its been convoluted. Diluted, maybe.

mg: The word personalization isn't in the SC language. This lessens the importance of what the SC title is. Almost every SC that has been worked on has been seriously modified in this process.

<JF> +1 to selling Metadata on elements, which is why I proposed changing the name to Metadata on Inputs

katie: this is not now about the purpose of a control. If the reason why we are doing this is address memory issues, then we need to speak directly to this issue. Autocomplete is nothing about personalizing anything, its about helping a person fill in a form.

<Joshue108> +1 to JF. Metadata on elements also works for Metadata on components, such as with React or Angular dev

<Glenda> +1 to Josh: Metadata on elements also works for Metadata on components, such as with React or Angular dev

jason: With the HTML5 autocomplete feature, it is supported by user agents. It isn't a specific accessibility feature, however. This SC doesn't meet an accessibility need that user agents don't already provide.
... I think we all agree that is limited in its impact. I genuinely don't think it is a good idea.
... I can live with it, but not enthusiastic about it.

<AWK> Brooks: make a clarification from my perspective

<AWK> ... my work has been on sites at large scale

<AWK> ... want to make clear that when we talk about burden on developers

<AWK> ... it isn't just developers making the decision

<AWK> ... business owners, content dev, designers, etc

<AWK> ... we shouldn't be too simplistic in assessing the impact for an enterprise

<AWK> ... volume of effort may be larger than we think

<JF> https://w3c.github.io/personalization-semantics/content/index.html#field-explanation

jf: The SC doesn't say that you have to use autofill. Just have to be programmatically determinable.
... There are other techniques emerging, which will be viable ways of meeting the SC.
... there are fringe benefits to this SC, such as helping users fill in inputs - much like benefits from alt text

steverep: The browser support doesn't match up with the end user benefit the SC is targeting.

<Ryladog> +1 to Steve

steverep: I have the same issue swallowing this that Katie is having. This SC doesn't directly address personalization.

<JF> +1 to AWK

awk: The reason why we had a problem with the original long list is that there was no AT/UA support. The shorter list we are using now has better support now.
... We anticipate greater support in the near future, such as a user-specified stylesheet based on programmatic determinization. We aren't saying this is the end all, be all solution for personalization. It will be helpful, though.

<Glenda> This really is a POC for pesonalization. A small POC. It will allow a simple personalization extension. Before WCAG 2.1 gets released. Currently limited to the diluted list of auto-complete…

<kirkwood> Or helping people to enter information in the amount of TIME needed to dfil out a form

<Ryladog> Katie is very curious about what Lisa thinks here......

<Zakim> JF, you wanted to ask Steve what his definition of "Personalization" is

Glenda: I see this as a proof of concept for personalization that just happens to use the autofill tokens.

<Joshue108> chair hat off: I don't understand the resistance to this SC. A perfectly formed, full stack personalisation suite will not drop shrink wrapped on our laps, and I think this is a really good start.

<JF> +1 Josh

Glenda: an extension will be built for this that will provide personalization based on the metadata.

katie: there are extremely robust accessibility metadata taxonomies available. organizations have been trying to figure out how to use the metadata for a long time.

awk: are you arguing that we need to change this SC, because we can't do that now.

<Glenda> Katie..it is NOT for each and every element!!!

<Alex> what do want us to DO?

<Glenda> This is a small POC

katie: I'm arguing that we cannot require that people edit each and every input to satisfy this SC.

awk: we approved this SC, its in CR and now we are looking for implementations. not sure that there is anything actionable, regarding the issues you are bringing up.

<AWK> You might meet this SC in the future using AT/ML

katie: what we are going to do is attach something to a specific element, instead of using artificial intelligence, or like heuristics that AT currently uses to make content accessible.

dm: 1.3.4 is out the door - Its in CR. We can't do anything about that now. We do have answer the issue that was raised about security, though. We have to go with this, unless we want to a recycle on this.

<Zakim> JF, you wanted to say there is nothing here that suggests you cannot use other metadata schemas

dm: I got good feedback on this SC from folks I've visited with recently.

jf: what i'm hearing from Katie is that we have to add metadata to all inputs on the page. All we are doing is suggesting that we will use additional attributes and fixed value tokens to extend the power of this SC.
... we want to add this additional metadata to the content so that machines will have additional semantic hooks that they can use to learn.
... this SC is not the only means to achieve personalization. There are more mechanisms on the horizon.

<Ryladog> Suggest move to GL 3.3 Input Assistance

awk: 1.3.4 is indeed in the Candidate Recommendation. We have work to do on implementations and understanding documentation. We cannot make changes to the SC text.
... There are some remaining issues, including whether or not the SC should move to a different guideline.

Techniques

awk: we need to start clearing the understanding and techniques documents for each SC that we are including, so that where's there is a need for techniques, we are going to have get writing.
... techniques don't necessarily have do be done simultaneously with implementation work, but we don't have a lot of time left to complete these tasks.

<AWK> https://github.com/w3c/wcag21

<AWK> https://github.com/w3c/wcag21#editing-techniques

awk: I want to make sure that people know what they need to do in writing techniques. Resources are available for writing/editing techniques and understanding documentation.
... we've had a lot of work going on with the task forces on this. Does anyone have any issues that want to discuss relating to techniques or understanding?

<Zakim> gowerm, you wanted to say I hope I'm doing it right :)

<AWK> https://github.com/w3c/wcag21/tree/aria-status-role

mg: I've gone through the process of creating a technique. I would appreciate feedback on the work I've done. I made a new branch for the technique itself. ARIA-Status-Role is the name of the branch.

<AWK> https://github.com/w3c/wcag21/blob/aria-status-role/techniques/aria/aria-status-role.html

awk: you made a new branch for a technique, that's great.

<marcjohlic> Here's the rawgit for Mike's technique: https://rawgit.com/w3c/wcag21/b10c86ab0e506d4faafe49e0f35832372a908866/techniques/aria/aria-status-role.html

<marcjohlic> (note - rawgit doesn't play well with the <code> </code> tag so his snipped doesn't show in the rawgit

awk: so far, its perfect. So far, it all looks good. You areare following the template, with examples and descriptions.

<marcjohlic> You have to look at the github repo to see the code snippets for his examples

mg: the actual code inside of the examples isn't displaying properly now.

<david-macdonald> second bullet "Determine if the container for the text is given a role of "status"." I think we'll need to rework that. people will think it means role="status"

awk: we'll take a look at that

<jamesn> <link rel="stylesheet" type="text/css" href="../../css/sources.css" class="remove"></link>

awk: we will spend a lot of time on the procedures, which is where a lot of time with techniques must be spent.

<david-macdonald> I think if we do this we'll need role="alert" and aria=live=true" etc.... I would rather a generic technique of

awk: Mike, what you've done looks good. It will need a few edits, but looks good.

dm: I would say we should just use aria-live and roles for these techniques.

awk: if people have questions or problems, let us know. If you address issues with a proposed resolution, let us know. We are going to start spinning up reviews of content. We need content to do that.
... Should we meet on Thursday to discuss specific issues related to ongoing work?

mc: I suggest that we use the time to work on CR evaluation.

awk: we will send out an invite for Thursday.

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/review 221 and 226. can you pass 221 yet fail 226/review 2.2.1 and 2.2.6. can you pass 2.2.1 yet fail 2.2.6/
Succeeded: s/honus/onus/
Succeeded: s/than we thing/than we think/
Succeeded: s/Your /You are/
Present: AWK JF Joshue108 alastairc jasonjgw Laura jallan kirkwood Greg_Lowney bruce_bailey marcjohlic Katie_Haritos-Shea Brooks MichaelC SteveRepsher Glenda Alex JakeAbma david-macdonald Mike_Elledge
Found Scribe: jallan
Inferring ScribeNick: jallan
Found Scribe: Brooks
Inferring ScribeNick: Brooks
Scribes: jallan, Brooks
ScribeNicks: jallan, Brooks
Found Date: 27 Feb 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.)