<scribe> scribe: alastairc

<Brooks> p+ Brooks

Survey: https://www.w3.org/2002/09/wbs/35422/Misc_Oct31/results (only #3 on Candidate exit criteria)

AWK: This carries over from Tuesday, making sure we are all agree.
... seems like Brooks is wondering if we can document a massive failure and have that count?

<lisa> link is not working for me

Brooks: It wasn't clear to me what 'providing accessibility support document' was? Could we just do a survey? Would the group then see if that's good enough? just wanted to better understand the intent of the language.

<lisa> working now

<AWK_> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria

<AWK_> "Have Success Techniques which demonstrate that each Success Criterion is implementable, using readily-available formats, user agents, and assistive technologies."

<david-macdonald> david-macdonald

AWK: Have to demonstrate that it is implementable in relevant technologies, and user-agents. Not sure it is necessary to call it out here, but open to suggestions. But need to make sure there is support that exists for each SC, and that's what the documenation would provide.
... e.g. an SC for alt-text with not supporting UA wouldn't be enough.

Brooks: Ok, should we make those clarifications part of the document that the world can see? I want to understand it, and have it be transparent so organisations know it's possible.

<AWK_> current version: https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0276.html

<lisa> https://docs.google.com/document/d/1YiknHDDDdKBdwVTEpxwUpyCaQL_tnpp9CfDlFjCq16E/edit#

AWK: Please do suggest changes.

Lisa: That doc is for the COGA TF to assign this work to people.

Alex: In 2.0 discussions we talked about a critical mass of AT to be available to claim accessibility support.
... I think that applies here, unless it has critical mass it can't pass muster.

Lisa: COGA is building techniques and implementation examples, for some things we have wide [something], some less so.
... Do we need examples for the implementation pages, or just for the control. E.g. for the COGA attributes do we have to show it for each attribute, or for the general concept?

AWK: If there were 5 specific things we'd need to show support for most of those.

Lisa: Compared to ARIA, did we have to show every role was supported?

AWK: We didn't say in 2.0 you need to support these specific roles, it said roles need to be correctly conveyed. That's part of the challenge (for the controls SC), there's three long lists of specific items/values that need to be supported.

Jason: On that point I agree that purpose of controls does require implementation to demo all the specific values are going to benefit users through UA/AT. That might not be onerous if it doesn't require metadata. For the exit criteria, we need a good argument that if authors implement it, then concrete benefits acrue to users. The only way to do that is to show UA/AT support for each.
... So the documentation does need to show that, so it isn't just fanciful / just existing in a research facility. That's why accessibility support is an important piece.

MikeGower: To the degree the SC puts a spec into the defintion (conventional names for forms/buttons/links), according to the wording it would need to test all of these, it can't just rely on just a few of those.

<Zakim> JF, you wanted to comment on Jason's point about 'assistive technology'

JF: On demonstrating it works with AT, that often means works with screenreader. We know that there are disability types that don't rely on specific tech. Secondary to proving it solves the problem. For Mike's point, we need to show that adding the meta-data can be abstracted to something else. Goal is to make sure that with those controls on the page, we can show it works, doesn't need ever single one to be done & tested. E.g. if it works on radio

buttons, it should work on checkboxes to.

<Alex_> +1 that technique has to show that it works

scribe: it would be great to have a test page for that, but don't know if it's critiral.

<gowerm> JF: If our definition includes a list of items that are defined as conventional names, and the requirement is to supply programmatically determined conventional names, then you have to meet the list. If the requirement is to just to be able to provide meta data, then remove the list from the definition.

Lisa: The question was, if you have something like auto-complete, or anything in the labels list, every single one is part of the auto-complete list. They work, if you type into something into the autocomplete list with a compatible UA that works already. Do we need to find 5 examples of every item?
... or point out that the autocomplete list is there and works, so find 5 examples from autocomplete (rather than all of them).
... Autocomplete is an (HTML) standard list of items for form controls, that's in the spec.
... Can we just point to the main spec for this working?

JF: Depends how we define that term in WCAG, and in the mainstream market place that often means SR.

<gowerm> https://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixA.html#atdef

<gowerm> JF: What is the problem with that definition?

Lisa: auto-complete is a huge benefit, so doesn't have to work with something that benefits the user. E.g. tabindex doesn't have to show it works with AT, just with the browser.

<JF> "Assistive technologies communicate data and messages with host user agents by using and monitoring APIs." - covers only a partial list of all AT tools

<Zakim> AWK_, you wanted to speak to the ASD requirements

Lisa: it helps that autocomplete works, doesn't mean that SR needed.

<JF> @gowerm a one-handed keyboard is also assistive technology

<gowerm> "provides services beyond those offered by the host user agents " a browser plug-in can be an AT, can it not?

AWK: It doesn't necessarily require testing with AT, depends on SC by SC basis. If it doesn't require them, we don't have to find them. For purpose of controls, we have a long list, to show each is supported, does it just have to show that the title is included? Or does it have to show that something uses that data and helps the user.

<JF> @gowerm, so is a mouth-stick, or a foot-switch, or sip & puff switch...

AWK: that's why we need to show that all the items do something for end users.

<gowerm> Those are all things that ride on top of the keyboard API, John. From a web author perspective, they make no difference to our authoring, right?

Jason: That's exactly the requirement, and furthermore AT is a fairly broad term and we can assume the broad meaning in this forum.
... E.g. the text to speech with highlighting, masking tools in Edu, single switch devices. Andrew's point is the larger one, it doesn't need a specific AT, it is true that AT is a broad concept and appropriate compatibility is necessary. If a feature is available in HTML that helps, but it needs to show benefit to users.
... without that it's impossible to show adoption. I don't know if we need to change the text to say that.

JF: Agree with that, need to use a broad definition. In some it will be hard to make a clear 1:1 mapping, it isn't always clear. We should think at a holistiic level.

<AWK_> I'm here

<AWK_> can hear you

David: So I think you're saying (Lisa) that these HTML attributes will kick in it's autocomplete abilities, then it will help people without AT. I had thought of it as something to add icons etc.

JF: A feature like autocomplete is what I mean, helps users.

Lisa: Autocomplete is a technique, there's an immediate benefit to uses these attributes.

<Brooks> +1 to explicitly requiring evidence of support for WCAG 2.1 techniques that yield immediate benefits to the user experience

<gowerm> What new SC are we saying is met by using autocomplete?

Lisa: We also have lots of people playing around with it, there are lots of implementations, but autocomplete has benefit right now.

<gowerm> Lisa, what new SC are you discussing?

Lisa: confused, it should be the user agent that needs to work, doesn't have to be AT.
... helps me fill in my email address (etc) consistently.
... why isn't this enough.

<gowerm> @lisa, can you explain exactly what SC you are saying is met by using autocomplete?

AWK: If we can demonstrate benefit to end users that happens as a result of UA/AT, that is the goal. If we can't, we have a challenge. We're saying the same things, but I'd like to bring us back to the exit criteria.

<JF> @gowerm "Purpose of Controls" - if you mark the form inputs correctly (programmatically), then autocomplete of forms is a net result

AWK: the exit criteria needs 2 implementations (not including 2.0 SCs), if it is done through a UA that is fine. If it needs AT, then it will need another part to the implementation. That ties back to the accessibility support documentation as well.
... Is there anything specific that needs adding to the exit criteria to capture this?

<AWK_> Accessibility support documentation for SC added to WCAG 2.1 with platform/user agent/assistive technology dependencies is available for at least two technologies

<AWK_> Accessibility support documentation that provides evidence of successful support for SC added to WCAG 2.1 with platform/user agent/assistive technology dependencies is available for at least two technologies

Brooks: Is this like a VPAT? Something that clearly says that we are going for evidence of success that yields immediate benefit.

AWK: Like the text I added above?

Brooks: Does that mean it provides benefit?

AWK: It needs testing with 2 technologies, to show it works.

<Zakim> JF, you wanted to suggest that perhaps "Understanding" docs will help define how we measure success.

AWK: The nature of AT support docs is to show it meets the SC, and the SC should provide benefit for end-users. If those SC don't provide benefit to end-users, something has already gone wrong there. I would rather not re-state all the requirements for SC.

JF: For all the new SC there is an understanding doc that outlines the benefit, so our testing strategy needs to draw from that document.
... then prove that it can be done in 2 different configs of UA or UA stack, which is whatever the end-user has.

RESOLUTION: leave open

<lisa> this is completely what the exit cryteria already

<lisa> nothing new

Brooks: Understand that, how do we get things rolling. The problem is when it can undermine delivery teams when you ask them to do a lot of work, and then cannot demonstrate the difference in user experience.

Understanding Survey discussion

AWK: We'll leave this one open, and we have 8 min, then we meet on Monday.

<laura> https://www.w3.org/2002/09/wbs/35422/understanding_SC/

AWK: There is a survey, please go through this before TPAC, it is on the understanding documents. Please go through that to prepare. There will be another one, please go through that as well, it will make TPAC more efficient.
... if people can make suggestions for text changes at the time of discussion, that is (whilst difficult) very helpful. This last item took almost an hour with one suggested change. It's been on survey for 2 weeks, it isn't new, need to get it defined and approved. Please think about how it can be improved with concrete suggestions.

TPAC Decisions

<AWK_> https://www.w3.org/WAI/GL/wiki/Meetings/TPAC_2017#Agenda

AWK Lastly, wanted to talk about decision at TPAC. I'll share the agenda link, have lots of issues to close from public and member comments. I assume people will either be present in person, or on the phone and want to discuss with the group our approach to decision at TPAC.

scribe: my expectation is that where there are changes we want to go through CFC. However, for issues, comments, do we support the idea of resolving them through consensus at TPAC, which should be a majority.

Lisa: The day we have it is the same day as APA, and sometimes I'll have to be there in the APA. Just had the agenda, but there will be clashes with TFs and other groups. I'm not sure if that works.

MichaelC: I expect there will be logs in IRC, what Andrew's asking is to avoid the long email process. Can you check the logs after another meeting?

Lisa: I can review it after, and say if there's an issue, *if* I understand the minutes.

MichaelC: A lot of the agenda is 'process issues', so the agenda it all that helpful for avoiding clashes.

AWK: E.g. if we try to agree a response to an issue, we are not word-smithing it during the meeting, then CFC, then wordsmith as well. We need to make decisions there in order to get the next draft out.

<lisa> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Main_Page

Lisa: Yes, if COGA related ones are deferred until I'm there that would help.

Jason: I'm also in the position of divided time, fine with the proposal: if it doesn't require changes to the draft without CFC that's fair.

Lisa: I can't follow the minutes half the time. If try to avoid the times from the link above (for COGA stuff), that will help.

<Glenda> Sounds like a good plan :)

RESOLUTION: Decision can be made at TPAC. We will group items with consideration to schedules, and do CFCs for spec changes

AWK: Please look for a survey soon, and the understanding docs...

<laura> bye

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)

Default Present: allanj, JF, shadi, jasonjgw, Glenda, alastairc, Makoto, MichaelC, Detlev, MikeGower, david-macdonald, Laura, KimD, Pietro, Alex, kirkwood, marcjohlic

WARNING: Replacing previous Present list. (Old list: AWK, KimD, steverep, JF, Kathy, Makoto, MichaelC, Roy, Rachael, kirkwood, shadi, Greg, jasonjgw, Detlev, bruce_bailey, Brooks, Laura, marcjohlic, Glenda, lisa)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK


WARNING: Replacing previous Present list. (Old list: AWK)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ allanj


WARNING: Replacing previous Present list. (Old list: allanj, JF, shadi, jasonjgw, Glenda, alastairc, Makoto, MichaelC, Detlev, MikeGower, david-macdonald, Laura, KimD, Pietro, Alex_, Alex)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ allanj, JF, shadi, jasonjgw, Glenda, alastairc, Makoto, MichaelC, Detlev, MikeGower, david-macdonald, Laura, KimD, Pietro, Alex

Present: allanj JF shadi jasonjgw Glenda alastairc Makoto MichaelC Detlev MikeGower david-macdonald Laura KimD Pietro Alex kirkwood marcjohlic
Regrets: Mike_Pluke
Found Scribe: alastairc
Inferring ScribeNick: alastairc
Found Date: 02 Nov 2017
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.)