Accessibility Guidelines Working Group Teleconference -- 22 Oct 2018

<gowerm> scribe: gowerm

<AWK> Scribe: gowerm

Process Update Discussion

Alastair: Decision process: quite a few things were brought up. Meaning of consensus.
... Opens W3C decision policy

David: Never vote if you can avoid it; consensus is not about voting

Alastair: It was aimed to be that if we have objections we need to work through them.

Katie: What is the new policy/understanding?

Alastair: We're keeping the same process but trying to clear up understandings

Katie: I'm misunderstanding this.

Alastair: Puts text on screen

<alastairc> Consensus is not a vote. The exact number of working group participants supporting a Call for Consensus compared to objections does not factor in the decision. Although significant support from the active membership is always desirable, consensus means working through objections until they are resolved, or the group needs to move on. In order to work through objections they must have a clear rational based on the technical merit or with reference to the

<alastairc> agreed scope of the work. (C2, C3). Moving on usually means a conservative approach is taken. For example, not adding something to the documentation.

<AWK> MC: ¨until the group needs to move on¨ leaves door open for arbitrary decision of when to move on; need to both prevent getting stuck in a morass by requiring discussion to continue until full agreement achieved, vs moving on when many participants feel not all the points have been considered

<Zakim> JF, you wanted to point to https://www.w3.org/2018/Process-20180201/#Consensus

JF: There is a consensus process. I've pasted it in.
... I want to make sure we are not deviating from that.

Michael: That is a voting process. Our decision policy goes on top of this. We should not conflict with that.

JF: There is a section on managing consent

Alastair: The top of this doc links to the w3c process.

AWK: Everything we're discussing is consistent with that process. I think it's about trying to focus the lens than change what it's pointing at.

Kathy: Instad of saying 'moving on' can we focus on the time frame we've set?
... We should try to work to resolve what the issue, but there is only a certain amount of time we're going to churn. So can we change "moving now" to something more time based?
... One of the challenges we had with 2.1 was trying to figure out what the timeframe was.

Kathy change "or the group needs to move on"

Kathy: it's a chair's decision, so can't we just say 'until direction is established or determined by the chairs"?

Alastair: I think I lifted that "move on" phrase from somewhere

Michael: Leaving the process open-ended has caused pain in the group
... We need to come up with a way that does allow us to make a decision over objections but doesn't make us too quick to do so until we're sure we've considered the objections and the consequences of overriding them

Kathy: But isn't that the chairs' decision?

Michael: It is, but this document guides the chairs.

<david-macdonald> "...resolved either through amending the decision or in rare cases overriding the objection"

AWK: Is it 'table the discussion' or 'table discussion and define criteria to reopen at a later date' There is often a lack of complete resolution that hapens.

Michael: Dicussion continues on github, email, etc.

Kathy: At the end of the day, if we don't resolve the objections, we have something put in place.
... we may add a note

Michael: Maybe adding a note can be part of the process

katie: I would agree with Michael.
... I feel like finding a way to either meet halfway or finding another option should be part of the process
... We shouldn't prioritize timeline over quality

JF: I keep going back to the consensus document. (Reads from w3c document)
... I'm not sure what more needs to be said.
... The idea of recording the decent and moving on could be better followed. We could take it out for wider public comment.

AWK: I think JF is right and Michael is providing more specific processes for achieving that.
... We need to be more disciplined about tying things off

David: I think what John just read is perfect
... I think what Michael said as an addition is useful.

<JF> https://www.w3.org/2018/Process-20180201/#managing-dissent

AWK: Do people envision that anytime there is dissent we should document?

Katie: I think for formal complaints

<Zakim> MichaelC, you wanted to say we need to avoid emergence of, or presumption of, bias in executing the process

David: We haven't had too much deep disagreement on techniques

Michael: I want to repeat that we need to avoid the emergence or even the presumption of bias.
... We can't always just move on.
... If we do it once, it's good management. If we do it many times, it can become structural bias.
... If we can find a way of documenting this better, it would be helpful.

<david-macdonald> "...resolved either through amending the decision or in rare cases overriding the objection as laid out in https://www.w3.org/2018/Process-20180201/#managing-dissent

Kathy: We can replace the 'move on' wording with the wording from what John read.

John: We want to avoid formal objections. We can have a process to go to wider review.

Alastair: A legitimate path to reopening needs to exist.

Lisa: I wonder if we need a different angle.

Three people objecting, two even from the same company, can result in things not getting in.

Lisa: I think structural bias is a good way to put that.
... Set up expectations -- people have to do reading before participating. We need to get user needs in.

<MichaelC> mc: think we´re talking about discussion here, not CfC. In a CfC, if the CfC fails, the default is nothing happens. In a dicussion, we should err towards having something happen, i.e., put in draft wording with ednote, knowing it could later be removed when it goes to CfC.

Lisa: We have to get over the structural bias we have in the spec.

David: I dropped a sentence in IRC

<david-macdonald> ...resolved either through amending the decision or in rare cases overriding the objection as laid out in https://www.w3.org/2018/Process-20180201/#managing-dissent

David: So I tagged on the word 'resolved'. I added in 'rare' which I believe addresses Michael's concern.

JF: I wanted to address what Lisa said, in regard to the comment on 2 from the same company
... At the level of calls for consensus, there's never been any pressure at Deque that members follow a line.
... They are autonomous members of the group. We don't block vote

Michael: I introduced the term "bias" I'm worried about structural bias, not organizational or individual bias.

Katie: When I was at Deque, there was pressure.

<jemma> what exactly does "structural bias" mean by Lisa and Michael?

Alastair: Responding to Lisa's comment, I have proposed a different way, but involves a complete overhaul of the 2.x document structure.

Lisa: To Alastair's point, I'm not suggesting we restructure the document, but the process
... We have a lot of people involved in testing and conformance. We have much fewer people understanding user needs.
... It is easier for them to block the progression. The user need isn't equally represented.
... What I'm suggesting is we take the user needs that the TFs are given, and then WCAG figure out how to do that.
... WCAG should figure out how to get something in that addresses the user needs.
... The process of WCAG changes to a strating point of 'we need to get in the user needs'

<Zakim> MichaelC, you wanted to separate general principles of making decisions, from specific procedures for working on SC

<JF> +1 to michaelc

Michael: When we do normative SC development, we still need to figure out how to achieve it. I don't think we can have a flow that says the WC must come up with SCs that achieve what the TFs want.

Alastair: I agree with Lisa, but I would reverse the approach. The TF needs to have the people that can help craft the SCs.

Kathy: One of the challenges, to Lisa's perspective, is that the user need gets lost.
... Especially with the COGA TF, where they had challenges using the tools, I think that got lost. If there is a major change, we seek input.

Alastair: My suggestion would be a more multi-disciplinary task force.
... You mix subject matter experts and more technical-specification-writing people

Kathy: I agree with that.

Lisa: Our Success Criteria were a disaster, but they went through three passes.
... We had many people from IBM involved.
... It's a structural process.

AWK: Steve Lee is here

Lisa: I think we need to start... The person writng the guideline has to get on top of the user need.

Alastair: We're veering off into how we structure the work, rather than the decision making process.
... We've going to be covering more on this later.

AWK: We've heard a lot of comments. We need to take a look at the text and tweak it.

RESOLUTION: Incorporate the feedback from today into another iteration of the AGWG process comments

<patrickhlauke> i'd say as a side note: yes, we *are* focused on the testability of SCs ... because by their very nature, they *need* to be unambiguously testable. which is their strength but also their downfall, as they don't allow for "common sense" nuance

<AWK__> +1 Patrick

Alastair: I suggested doing single topic CFCs.

AWK: It was proving impossible to reach a decision on some calls.

Alastair: Read out item 3
... Read out item 4 in the document
... Some text was added in about 'chair's and staff...will come to an agreement'

AWK: And that already happens

Alastair reads out item 5 in document

AWK: We have a decision log that we updated all the time. Is this different?

Alastair: We spoke at teleconference about 4 weeks ago about having a change log that included new techniques.

AWK: So what is the level of detail for the changelog?
... Groups working on techniques want a more granular...

Michael: We'd use github for that. This would be much higher level, much less granular.
... Changelogs link to git history, for people who want more.

<AWK__> ACTION: Chairs+ Michael to review decision policy and make updates related to discussion

<trackbot> Error finding 'Chairs+'. You can review and register nicknames at <https://www.w3.org/WAI/GL/track/users>.

2,3 4. Timline, tools and volume

Alastair: Task forces use google docs/wiki/github. SC managers used github issues.
... There were lots of comments that led us to a more centralized editing process.
... We'd need to extend the number of editors.

AWK: Some groups felt there was pressure to work within github, and that was problematic. We wanted to make it clear you can work where you are comfortable.

<JF> ACTION: Chairs + Michael to review decision policy and make updates related to discussion

<trackbot> Error finding 'Chairs'. You can review and register nicknames at <https://www.w3.org/WAI/GL/track/users>.

AWK: At some point, things need to go into a managed document system.
... We thought github would be easier than our arcane stuff; github is easier, but it's not easy.
... We want to exploit the people who are good at github and like doing it.

Alastair: We need a better method of previewing things, especailly because rawgit closed down. There are other options.

Kathy: Having a set of recommended tools and instructions on how to use them would be very valuable.

<Rachael> +1 Kathy

<jemma> +q

<jemma> what is the process/requirement to be the "editor help" or the "editor"?

Alastair: Does it help when you take people through the tool?
... Which is why we're suggestion to have a small group of people.

Kathy: Inside the TF, we had a large range of tools. It was hard as the facilitator to keep track of it all.

Michael: Dealing with that would be in the job description of the editors.

Kathy: It is very time consuming.

Michael: Editors and TF facilitators can be different people.

Jemma: What are the requirments for being an editor?
... Do I contact the chairs if I'm interested?

AWK: Yes.
... But not yet.

David: I think it's a good idea. There's going to be a barrier, but we need to be in github, so it lets people be in the medium of their choice.

AWK: The job of editor ends up being easier than co-facilitator because they are told where to get the information

<jemma> I like to second the idea of having mulitiple editors

AWK: Hopefully we can have a WCAG 2.1 conforming AND usable tool.

David: Showing how to put an issue into github seems like an easy task.

<jemma> because each editor can contribute on different aspects of editing - git hub expert, editing expert, so on

JF: Does it make sense that each TF has an associate editor?
... Would that help?

AWK: Possibly. Something else we have to talk about -- on the agenda for tomorrow -- is what the TFs should be expected to do.

<jemma> I have different opinion about "associate editor" idea.

<Kathy> scribe: Kathy

Alastair: talking about editor and review process

editors create branch, that becomes available to preview

read comments on issues, goes back to preview

public reviews and comments goes into comments

we will have previews

AWK: we would not be using Github issues for SC to start

if we are talking about 2.2 we may focus on a small set of things

with those decisions we will look at a-e

<jemma> ARIA APG use this process for now

Alastair: does it make sense to centralize editing

who can do what and who is doing what

David - it is good

AWK - return to what we are doing before in 2.0

Jemma - ARIA APG is using this

hard to find closure

people keeping commenting but goes on and on

issues do not get closed

AWK - the issues would be smaller and more resolvable

there could still be bigger issues

working group review would be granular so that they are resolvable

MG - are you saying we handling of the questions would be in the taskforce so smaller set of issues on the SC

Alastair: it would be multi-discipline

MG - will the process be that the chair will label items for review

Alastair: the editors would label it

<Zakim> MichaelC, you wanted to say I anticipate an editor management process

MC: there would be a editor forum that will coordinate the review and closure process

Alastair: in 2.1 everything went into a big pot, we need to break down better

we either pick a set of issues until they are done

so there is a smaller set that we are working

the other option is a conveyor belt of changes

David: 70 SC is too large, we need a smaller set

John: quality vs. timeline concern, we need a timeline so like picking a group or conveyor belt idea. More focused time is good

Alastair: we could have 15 things and 18 months... so we will start on 3-5 SC now and then continue on

so we are managing the 18 month period

MC: it is likely we will get stuck on issues, if we force completion we will get stuck so prefer the conveyor

need a slower and faster conveyor belt

<jemma> "move on" in alternative 2 sounds like "multi-tasking" to meet the timeline.

<Zakim> MichaelC, you wanted to propose fast and slow conveyor

Rachael: concern about both we were lost time going back and forth over conversations that happened before

would prefer to finish something to completion

MG: not clear in the model how this goes back to the taskforces

not just a conveyor belt, needs to have loop to the taskforces

<Zakim> AWK__, you wanted to discuss the benefits of only one conveyer

AWK: challenge we had, slow may be taskforce process

since we only have a finite amount of time

<jemma> I think Alternative 2 does not mean we abandon the issue.

<jemma> some issues just need more time to think/receive the comments

it may be that we don't have consensus and we need to move on

<Zakim> MichaelC, you wanted to say done isn´t one because of intersecting context

MC: done isn´t one because of intersecting context

need a harmonization phase

in 2.1 we rushed into it

KW: still need to go and get feedback from the taskforce even with AG participation

<Zakim> JF, you wanted to ask about a 'standardized' TF sign-off

JF: maybe one of the process we can have taskforce sign off mechanism

the editors may help

communication process

maybe a checklist to have the different touchpoints

AWK: it is an approach to consider

Jeff: you rock! lots of issues that didn't get resolve and happy to see that looking at the process

going forward we need to make sure we are not going too fast

Mike: will it ultimately be the taskforce who decides the number?

AWK: to be decided tomorrow

Alistair: behavior issues

the disagreements have led to a communication gap

move the collaboration earlier

there is a code of ethics / code of conduct

<alastairc> https://www.w3.org/Consortium/cepc/

please read and take this to heart

AWK: it is helpful to talk to the chairs or Michael

people should not feel that there is an inner and outer circle

there is a process to raise concerns

and discussions / actions are taken

there is a large diverse group

we will conform to the code of conduct

we will do our best to be a safe and productive place to work

MC: when people raise the concerns, there is discussion but may not be discussed with the larger group and may be handled differently

BREAK for coffee

Silver TF Update

<AWK> JS: Lots to show

<AWK> ... goals

<AWK> content easier use, reference and understand

<Lauriat> For those who'd like to follow along in the slides: http://goo.gl/XqwaM4

<AWK> ... more inclusive and useful

<AWK> ...based on on evidence and data

<AWK> (based on slides)

<AWK> Milestones to date

<AWK> project approved Oct 2016

<AWK> (see slide)

<AWK> Silver design sprint at CSUN 2018

<AWK> Working on requirements document - last shared in June 2018

<AWK> Proposed timeline to recommendation is Q4 2021

<AWK> (37 months from now)

<AWK> Want to publish editor's draft of silver this quarter

<AWK> plan is to roll silver normative work into next charter

<AWK> CR at end of 2020

<AWK> Prototypes

<AWK> (slide 7)

<AWK> organize the information in small snippits for easier remixing

<AWK> offer a comprehensive view

<AWK> enable role-based location capabilities for spec

<AWK> (slide 8)

<AWK> flattened overall structure - GL and methods

<AWK> (slide 9) - Hessite diagram

<gowerm> (slide 10) How WCAG content...

<AWK> GL and SC become Guidelines

<AWK> Tech specific SC and TEchniques become methods

<AWK> no more A/AA/AAA - more on conformance later

<AWK> no more SC numbers

<AWK> (slide 11)

<AWK> (slide 13)

<AWK> (slide 14) what this looks like in action

<Zakim> JF, you wanted to revisit the Hessite diagram slide

<AWK> JF: Have you built out the taxonomy of tags for silver?

<AWK> JS: THere is a separate doc with tagging ideas

<AWK> ... needs more work

<AWK> ... prototype isn't comprehensive

<AWK> JF: mentioned that the 2.1 numbers would be tags

<AWK> ... but no number?

<bruce_bailey> +1 to @JF concern about trying to keep number

<AWK> JS: we intend to get rid of numbers but people can still search by it if they remember from earlier

<AWK> JF: why not continue using numbers in some way

<bruce_bailey> numbers might map 1:many or many:1 from 2x to Silver

<AWK> JS: The experts that know the numbers are hostile to non-experts, so becomes a barrier

<AWK> SL: The numbers are also related to the InfoArchitecture and we are flattening that

<AWK> JamesN: Concern that there is a need for some identifier - and the numbers cross translation boundaries

<AWK> PL: agree that it is unambiguous and needed.

<alastairc> Silver issue for exploration - Unique IDs for each criteria that works across languages.

<Zakim> jamesn, you wanted to ask about internationalization

<Zakim> david-macdonald, you wanted to say "discuss overlap of EO quick ref tags with proposed tagging" and to ask "Does the distinction between guideline and method have anything to to do

<AWK> SL: yes, looking at the testability to be attached to the methods

<AWK> SL: We hope to test out the model in an experience later in this session, with you all

<Zakim> bruce_bailey, you wanted to ask if anyone can think of another word besides "guidelines"

<AWK> (slide 16)

<AWK> JS: plain language

<Lauriat> Experiment in Plain Language: https://docs.google.com/document/d/1BGr0XSQgjBSVDG_Xn9MoodEq01cJxgg_EE0bniXONXM/edit?usp=sharing

<AWK> ... built a prototype using what was learned to create a tab-organized interface

<AWK> ... keep in mind that some SC can be combined (e.g. color contrast with aa/aaa versions)

<AWK> ... also working on a editorial style guide

<AWK> (slide 17)

<AWK> 4.1.2 was hard example

<AWK> Some things in plain language version of 4.1.2 move to methods

<AWK> KW: There were issues that Mobile TF encountered in dealing with keyboard access issues that need to be addressed

<Zakim> alastairc, you wanted to ask whether they are content requirements, or user requirements?

<AWK> AC: are these content guidelines or user requirements?

<AWK> JS: the direction is toward focusing on user requirements, but aren't there yet

<Ryladog> I like the concept of User Requirements

<AWK> Looking at plain language prototype

<gowerm> (slide 18)

<AWK> JS: getting started section

<Ryladog> https://docs.google.com/presentation/d/1V_nYD27N6kx8gRha0rrdQK8aKyvg7kKXu6rs44We7IU/edit#slide=id.g44ab6d0383_7_7

<AWK> sections: Why, who it helps, technologies, examples

<Lauriat> Plain Language prototype on github: https://w3c.github.io/silver/prototypes/PlainLanguage2/

<AWK> Also provide information about planning responsibilities, tips for collaboration, method links

<AWK> Usability methods are new in here

<AWK> in design tab

<AWK> Design responsibiilties, How guide, designer tips, user testing, methods

<AWK> JS: develop tab - needs to be fleshed out

<AWK> TEst and audit - still sketchy

<AWK> meeting with ACT about this later

<AWK> JF: asked about using roles

<AWK> JS: lots of pushback, instead organize around activities

<AWK> ... e.g. one comment about the designer role was that IBM has 30+ types of designer roles

<AWK> KW: one of the challenging aspects of looking at (lost the thread)

<david-macdonald_> http://www.davidmacd.com/blog/what-are-WCAG-success-criteria.html

<Zakim> AWK, you wanted to ask if all parts are intended to be normative (e.g. guidelines, methods, etc)

<bruce_bailey> Thats what I was saying, that the Guideline being the normative text could be okay.

<bruce_bailey> The VVSG1x normative parts looked like 2x SC

<bruce_bailey> The VVSG2x normative parts look like 2x Guidelines

<AWK> JS: that is still in progress, including talking with Wilco/ACT

<AWK> JS: different prototypes differ because doing user testing

<AWK> DMD: The prototypes that I've seen don't address all of the issues that we needed to deal with in WCAG 2.0. Need to focus on how to solve those problems, but right now the problems still seem to exist.

<AWK> CONFORMANCE

<Detlev> scribe: Detlev

<AWK> JS: goals to move toward measurability from testability

Jeanne: aim to move beyond pass / fail testing to accommodate Neds eg of yoga TF
... Should be measurable but go beyond P/F include things like usability
... developed a points/ranking system to give more flexibility to do more advanced accessibility
... conformance will have an overall score (for web site or other product)
... wanted to get rid of A / AA / AAA because many people thought WCAG A is best
... suggestion to fall for Bronze / siver / Gold because everyone understands it
... cater for cases where small issues cause failure
... remive accessuibility-supported
... inspired by Leeds Green Building assoc
...goal: reward desirable behavior, things that goes beyond minimum standard
... assigns points for the methods
... individual methods feed into a point scoring system that can differentiate by type of product (static, web app, etc)
... as new products come on the market, new point scoring systems can be developed

<alastairc> I'll go through the Q when Jeanne has finished.
...goal: developed a spreadsheet to assign points worth to particular methods
... was difficult ( a rattle)
... easier for people who are not familiar with tech details can point to scoring as neutral
... point scoring system will then result into a grade (bronze/silver/gold)
... possibly passing everything that meets WCAG 2.1 to silver
... aim to talk to people that have testing expertise to refine conformance model
... grab Jeanne or Shawn to contribute your experience

Kathy: so conformance is based on individual methods not P/F of SC (now Guidelines)

AWK: can people do particular things extensively to make up points when they fail to do things lie AD?

Jeanne: yes

Kathy: raises lots of legal issues

<alastairc> q

Kathy: when you check if stuff meets guidelines in terms of conformance, but that does not imply it is usable
... is this something you have considered in Silver?

Jeanne: It is hard but doable - people familiar with user testing say you can set up valid measures (based on e.g. rule sets that improve validity of user testing)
... get more people involved that do that part of it
...Jeanne: the idea was to take what is good in WCAG but move forward to include usability
...Kathy: You can have different types of users
... experienced / not experienced

Jeanne: we promised an editor's draft

<Lauriat> Link to the Editor's Draft from the presentation: https://w3c.github.io/silver/prototypes/EdDraftPrototype/

Jeanne: still sketchy but takes what is in the prototypes into a TR doc
... how WCAG content can move to silver
... there is an example for (plain language) section headings
... the listing the methods, a conformance section
... then levels, issues that need to be solved
... so thi is how it could look - need to define the prototypes through user testing, then publish for public comment

Shawn: Questions around conformance models, Silver TF is aware that many more questions are being raised than can currently be answered

AWK: conformance is such an important topic that wee need a discussion WG meetings on it

Jeanne: We need more help in silver
... comments on requirements - they won't be completed before the prototypes are finalized - especially conformance requirement

<JF> Pasting this in IRC related to conformance discussion... http://bikewinnipeg.ca/wordpress/wp-content/uploads/2015/02/SWRT_Bike_Parking_IMG_7281_2_3_tonemapped.jpg

MichaelC: The requirements should come first, then Silver needs to address it

Shawn: this was known and taken into account when drafting Silver

<JF> (NOTE: in Canada, many folks jokingly refer to the city as "Winter-peg" (Winnipeg))

AWK: The TF has asked to skip conformance now but we need to hammer it out soon

Jeanne: input needed on design, usability tests

Shawn: lets get into queue

<Zakim> gowerm, you wanted to say that the NEED for tagging sounds like a flag for a failure of data normalization

<AWK> AWK: The requirements document needs to get a full review and approval from the WG - most questions may have been about conformance but that doesn't mean that there aren't other concerns.

<Zakim> Wilco, you wanted to ask about multiple methods per technology

mGower: tagging as a possible solution to difficulties in hierarchy (observation)

Wilco: what happens to UA and AT if accessibility support is going to be dropped as concept?

Jeanne: what came out of design sprint the concept of accessibility-supported was to have advice ... having individual authors being responsible for a-s was leading to a proliferating number of dfiferent sets, hard to handle and not helpful in total
... non-english folks also have difficulties of meeting WCAG due to translation
...result: more plain language instructions how AT should behave, that is easier to translate
... we wanted the Carrot not the stick, give better advice to lead to an overall improvement of accessibility-supported
... hasn't been a strong focus, its on the list of things to do

<Zakim> Ryladog, you wanted to talk about test at design, and test in Dev, as well as test in QA and to discuss that AS includes using the technology correctly

Wilco: agree with carrots not sticks

Ryladog: we still need testing as part of the picture - quoting a questionable advice on a website - sticks are still needed
... use the technologies you use correctly - language aspect is very important to make clear of what the AT needs to do
... want to congratulate Silver TF to put together this first draft!

<Zakim> JF, you wanted to talk about gaming LEEDs

JF: about idea of using the Leeds model - but this model can be gamed - an airport got extra points by introducing bicycle paths that are fairly irrelevant
... does that mean on doing something on different user groups

Shawn: System should not allow to be gamed

Rafal: what do you mean by "product" - how are guidelines applied to different products?

Jeanne: example of assistive living product that wasn't suitable to hard-of-hearing people
... mandate was to include AT and UA guidelines - called silver because it goes beyond web content
... that hasn't happened for political reasons
... but the architecture should be flexible enough to take on board new types of content beyond web content

Shawn: don to categorization - how do you delineate a product that may be accessed via different UA - so what is the product in different platforms and UA - open questions

<david-macdonald_> https://new.usgbc.org/leed

Alastair: if guideline level is a user requirement, then it is easier to add authoring aspects

<Zakim> gowerm, you wanted to say measuring by an ability to carry out a task by sense and/or modality if an approach that may get us out of the woods

mgower: did accessibility stuff for physical games, did asks by sense / modality - instructive what the challenges are - there are restrictions on the web - no coverage smell vibration, beginning to include voice
... if applications check of different modalities, then you need to meet a bunch of requirements
... the reporting thing is no longer focused on particular modes

Jeanne: is this the right thing to go?

<Kathy> Here is a background doc on Leeds - http://www.usgbc.org/sites/default/files/LEED%20v4%20Impact%20Category%20and%20Point%20Allocation%20Process_Overview_0.pdf

mgower: yes, a bit nefarious

David: had lots of problems in defining the conformance model for WACG - restricted to web page was already difficult - how can you scope it?

Shawn: Thant is true and one reason to put in effort into working this out for web apps and more complex things
... so some guidelines may apply at the web app levels and others at a component level, also include a collection of user tests, to expand beyond technologies

Davide: Where it starts and stops may not be solvable - would conformance be based on a collection of tasks?

Shawn: yes

<Zakim> patrickhlauke, you wanted to comment on the "beyond web content" slippery slope

Shawn: important also for home assistant systems

Patrick: Sees a problem haw particular types of content fall under WCAG (link documents) they should fall under it but it doesn't seem right - this seems to go further towards blurring the boundaries - is there a rest to loos the focus of the AG?

Shawn: Drawing the boundaries for this has been one of the key problems (don't want to 'boi the ocean' - but stimm extend beyond the boundaries of the current model, e.g. for streamed games that end up on the web
... have large collection of examples that illustrate this (boundary) problem
... lets add new stuff, work with the WG to get it right
... for including the method it needs interaction with technical people

Jake: wondering if Silver considered a layered approach? Hs being busy to sell wcag in the way Silver approaches (the carrot way)
... focusing on the functional approach to sell accessibility - bronze-silver-gold may be good but the olympic model suggests that the rating is for very specific things not added / ancillary stuff
... if there are accessibility issues that block access they need to be addressed - cannot purely be based on usability

<patrickhlauke> adding to the above from me: i already have a hard time conceptually reconciling how Word or PDF falls under WCAG, as they're "on the web" rather than "of the web". i see this even more tech-agnostic approach proposed here to bring up even further problems that would take Silver beyond "web" (e.g. if you look at native apps), and even beyond the remit of W3C as an organisation

<patrickhlauke> i.e. is W3C in any kind of position to write guidelines for something completely NOT related to "web" per se? (and further...what IS web then...something that uses TCP/IP? HTTPS? etc)

Jeanne: experience from writing normative stuff for UA suggested the carrot approach - what silver does should definitely be able to be used in a conformance / regulation environment

<alastairc> patrickhlauke - not saying Silver should try and cover everything, but it would be possible to allow for more, especially if we map the fucntional statements used by things like mandate376 / EN thingy, http://mandate376.standards.eu/standard/functional-statements

<patrickhlauke> if we do want to have a generic "digital products/content guidelines" then great, but that likely goes beyond the remit of W3C

Jeanne: not the primary goal though because doing accessibility should be easier to do - feedback suggested that people would do more if it was easier to use / understand

Ryladog: that does not make implementation easier though

Jeanne: Point is we are not getting rid of the stick

Jake: The problem is to transport accessibility when you talg about functions, wireframes etc

Jeanne: So there should be guidelines for accessibility too

<Zakim> Raf, you wanted to ask about connected devices

Rafal: likes usability focus - will it include guidelines for devices (like physical features of home assisitant devices)?

Shawn: It is probably a later step, focusing first of guidelines for web content

<patrickhlauke> and this (actual physical device features) is exactly the kind of scope creepthat would take this beyond the mandate of W3C

<patrickhlauke> in my view anyway

Jeanne: probably not part of first silver recommendations

David: Historical conversation is that the web delivery mechanism is used it applies, not if it was got to by FTP

<alastairc> patrickhlauke - noted, and something to watch for at charter time, in the mean time the focus is web / of the web.

Patrick: distinction is difficult because the browser may load a word doc

Shawn: Homework for everyone s to try out / look at IA at the test drives

<alastairc> Plain language template: https://docs.google.com/document/d/e/2PACX-1vQVTxM2r00NtcYhZJY6lN6xh_fuM9L2jnPZQJ2c59KiyA_-BcC2HkhKf0IxDod4qBunvPkXbhkCHuKq/pub

<alastairc> IA template: https://docs.google.com/document/d/e/2PACX-1vRgf85Z_NJ7HmF-UX992wLx0F-sCQyipL6USL9HTmvBOWtH53C78SVNjKI8kLTxl5UuYJbc7ImiGsB_/pub

Shawn: try translating existing SCs, including those that did not make it into WCAG 2.1 - email results to Silver to see whether the IA holds
... second is the style guide to translate current content / SCs into plain text versions - let's see if it works and what obstacles we run into, identify problems

Kathy: So if the goal I restructure, why do a one-2-one translation?

Jeanne: Brause we knew the guidance which should be kept, but transformed - what would it look like in plain language
... like contrast can be doe in one guideline now - interesting for stuff that dd nit get in into WCAG 2.1 to see if it would fit into sivlver
...Kathy: not easy

Shawn: but do it to generate results

Kathy: we may not have enough inc of the full picture to see ho things interralate

<AWK> Scribe: Ryladog

<scribe> Scribe: Ryladog

KW: I am concerned about trying to fit in the individual pieces, but they havent looked at how the GL are going to fit together. I like what they've done, but they havent looked at th critical issues we had in 2.1

DF: The proposed that the Guidelines are like SC and Methods are like Technique

AWK: I think it is very important that different methods get you to a different endpoint

DF: The German grading system has a points. We see somethings are mapped to SC. You have score points for say landmarks, heading and skiplinks
... I could see that users could e left out if you get morepoints for one type of disability than another

DM: I thought they would be dividing them up

DF: But there would be a limited number of points per GL

DM: I would imagine that the points from this group would spill over into this

DF; But they said it would be flat

MG: There are certain SC are going to be bad if you dont pass them. I would be concerned about passing a severity such as 2.1.2, there are very few SC

AWK: there are the 4 conformance SCs. But yeah, you have failing due to having a poor title,

DF: In the German grading system, if keyboard accessibility is not good, then it is downgraded

KW: What if its in the footer

DF: You look at the entire page
... That goes into the equasion as well, there is some subjectivity

<patrickhlauke> subjectivity is the dirty reality of WCAG testing, even today...

DF: That is why the German has two testers working together. It is subjective

DM: The plain langauge versions they are going to have to redo the style guide. None of the SCs would be starters
... Every word has such weight. You might want to go for accuracy and then have a plain language version that is not normative

DF: If you make it a Guideline not the determining factor
... It would be taking all the verbosity out

How can you have technology specific things that dont go out of date?

AWK: you have to update

DM: If you are updating every 18 months than you do not have to make them so verbose

Jake: the methods did not work on how to get people to judge a certain GL. We need to provide guidance on how to ake a judgement call
... on the other side, the usability of a product is not set in stone. If you only provide the technical guidance that is not the right way to provide the understanding
... Silver is eager to hear from us

MG: Like alt text it is almost impossibleto technically check how correct something is. How is it technically provable

KW: Trying to understand their idea of conformance model. And the feasibility, and that bussiness will have to add usability and this list and than it will still be subjective

AWK: No one one is going to want to see diminished quality
... Maybe there is user testing in Gold. But I see pushback that required user testing

ACAA requires use testing with disabilities

DM: It is about abilities
... Is a very broad definition
... But how effective is that?

<gowerm> 1.1.1 is programmatically achievable, to the extent that ALT="[string]" is a pass. But the value and quality of the string is highly subjective. To Jake's point, how valuable is just the technical achievement of putting a string in ALT as opposed to indicating how usable the string is

DF: It looks like Triple A would be Gold, and so maybe folks wont even go there
... There is the possibility to have less SCs for forms
... There is the opportunistic to simplify

Jake: that is still the technical, not what are the blocking issues o use a form, which is what they are trying to do

DF: Everything that calsl for user testing would not be part of Silver level

AWK: I have can imagine many orgs saying that they have tested.
... What we should do, look carefully at the Silver document. Last we havd very little context. Now we have more
... What we have now is more aspirational than technical
... Timeline too. We have stated that we want to keep WCAG current, instaed of waiting 10 years. If we want a 2.2, or the next step or do we feel like Silver is what comes next
... They say probably 3 years

MG: Does anyone think we are not going to be a 2.2?

DM: There are alot of issue that have not been solved
... They are expertise, of overcoming the problems that we have had to face, then need our inputthat are hardening like measurabily, I am nervous outside of our group, without our working with them
... They are speaking at conferences all around the world as that this is what web accessibility is going to be - without us

AWK: If we were in a position, OK we dont really have anything else to do. It would be good for the people here to help evolve that model

DM: They didnt have the benefit of the folks who have grpped with these problems

Jake: It is always to good to improve a standard, what are they trying to solve? Is it selling accessibility to everyday developer?

AWK: The scope of work in the task force statement

<AWK> https://www.w3.org/WAI/GL/task-forces/silver/work-statement

AWK: options, etc
... research studies

The work of the task force includes: Propose options of plans to update the Accessibility Guidelines WG and choose an option; Identify stakeholders; Design research studies and timelines to perform research about appropriate structure and features of future guidelines; Perform research and report on findings; Interpret, analyze, and report on research findings; Create and refine prototypes and choose an option; Develop Requirements for Silver; Write an initi[CUT]

AWK: It grew out of the basic idea for current WCAG structure as broadly as it has been applied
... Sometimes it is redundancies
... do we need to do something different with user agents that speak to accessibility support

PL: there was a desire to move away from pass/fail
... a more nuanced approach.
... target size you would want to important controls is not normative langauge
... That was one of the conversations I had with Jeanne

DF: Now we have all this overlap
... Groupp those things together

Alistair: they did a survey of all kinds of users

Jake: There is a difference, guideline, methods and tagging

DF: I dont see how tagging/using the principle helps

Jake; How do I guide people in my org to build better things, how to change culture

DF: You have to have some order independent of language. On the level beneath the GL there is the same rigor for confomance
... It is not so difficult. I will try to add more time to Silver

Alastair: They wanted to be adaptable

GM: WCAG is not condusive to people learning it

MG: Test what is not working about it. Sometimes it is hard to map to SC

AWK: we can still talk about this

DM: I would like to see our atcivities be 50% on Silver 50% on 2.2
... We are too unattached
... Not enough of our melding of the cultures

DF: Which SCs did not make it into 2.1, if not...

Alaistair: we are going to discuss that

AWK: there are somethings that didnt make it, that we could have done a half step. Sometimes that gets you somewhere

Jake: Were done

AWK; Congrats the web is done

AWK: Lets review the Silver Requirments, and I think David is right, we need to interact more regularly

<david-macdonald> Here's a list of SCs that didn't get into WCAG 2.1 http://tinyurl.com/jmo9st4

DF: Is there some process? It would have been good for them to listen to?

AWK: Shawn said just come talk to us. It will be a richer discussion when we address thing together

DF: There is a critical, and that many people see risk

Techniques

AWK: One challenge is where is the list of techniques?

AAWK: Opens EXCEL doc - going How to Meet, there are no Techniques

AWK: there are fewer techniques that we want to have, at this point in time
... this is all three kinds of techniques

DF: Is it synchronized?

AWK: this is a Google Sheet, a wiki is aweful

<AWK> /www.w3.org/WAI/GL/task-forces/silver/work-statement//www.w3.org/WAI/GL/task-forces/silver/work-statement

<AWK> Sheet for Technique: https://docs.google.com/spreadsheets/d/15idlBl1qQTNr2SIi4Drzk1Q1vnWAi5L26GCCv6mjD2g/edit?usp=sharing

AWK: What would be helpful is to shorten the names of some of these Techniques, and identify type and Priority.

Aways possible to get distracted bya technique that seems simple but is really harder to work on

AWK: To start, this sheet just has the twelve new, and Kathy has the mobile techniques. Find where all of them are on Task force pages
... Which ones do we really need first?

Do we want to have a least one per SC?

AWK: Yes, we want to set an optimal goal, not by the end of TPAC but maybe in 2 months

<alastairc> scribe:alastairc

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.1_Understanding_and_Techniques_Development

AWK: Some criteria might be harder than others. Would be good to have techniques for each SC in 2 months. Might not happen at TPAC, but soon.

General page we had been using: https://www.w3.org/WAI/GL/wiki/Wcag21-techniques#List_of_Techniques

<scribe> scribe:Ryladog

AWK: Do we focus on failure of sufficient techniques?
... What I think, these are all of the techs that we have thought about, we feel that this is step pne
... Which ones are we really going to dig in on first?
... This list is what is in the Techniques document
... Let hone this list - it needs to map to reality - we had empty links for 9 years
... If we think writing a title helps people understand, then that is good, just not an empty link

DM: We have never been that successful at outsiders providing techniques

<AWK> https://www.w3.org/WAI/GL/wiki/Wcag21-techniques

PL: I have the best intensions, but the elast time

<AWK> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.1_Understanding_and_Techniques_Development

AWK: Do you want to just grab one

Reconcile this list with what is one the wikipage

<JakeAbma> https://docs.google.com/spreadsheets/d/15idlBl1qQTNr2SIi4Drzk1Q1vnWAi5L26GCCv6mjD2g/edit#gid=0

<bruce_bailey> in 2.5.4 line 131 might duplicate 138

<alastairc> There isn't anything in 138, do you mean "Not using the device motion..."

<david-macdonald> https://developer.mozilla.org/en-US/docs/Web/CSS/image-orientation

<alastairc> "Changes in content or functionality due to the size of display are not covered by this criteria which is focused on restrictions of orientation." https://www.w3.org/WAI/WCAG21/Understanding/orientation.html

<AWK> https://docs.google.com/spreadsheets/d/15idlBl1qQTNr2SIi4Drzk1Q1vnWAi5L26GCCv6mjD2g/edit#gid=0

<laura> Thanks!

<alastairc> PR with the examples: https://github.com/w3c/wcag/pull/386

<bruce_bailey> Regrets for tomorrow.

<laura> Thanks, everyone.

- DRAFT -

Accessibility Guidelines Working Group Teleconference

22 Oct 2018

Attendees

Contents

Process Update Discussion

Silver TF Update

Techniques

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output