Accessibility Guidelines Working Group Teleconference -- 02 Apr 2019

<AWK> Scribe:JakeAbma

<scribe> scribe: JakeAbma

new W3C specialist

<bruce_bailey> woot

MC: Joshue O Connor got emerging technologies web specialist for W3C

TPAC 2019 (https://www.w3.org/2002/09/wbs/35422/AGWG_TPAC_2019/results)

AWK: everyone thinks we'll should meet with SIlver
... need to submit if we meet, answer is yes

RESOLUTION: WG will meet at TPAC

Finishing Silver requirements discussion (https://www.w3.org/2002/09/wbs/35422/SilverRequirmentsReview/results - only questions 19-21)

requirement 7

<bruce_bailey> http://www.w3.org/2002/09/wbs/35422/SilverRequirmentsReview/results#xq18

<AWK> Motivation: The use of the guidelines supports and motivates organizations to acknowledge gaps and strive to be more inclusive. The intent is to give organizations a path toward greater accessibility.

<JF> Principle

<alastairc> For Requirement 7, Shawn outlined a choice between moving this to the principles (instead of requirement), or adding some measure-ability.

AWK: do we see this as a design principle OR requirement

<alastairc> Wondering what the measures could be?

JS: think we need to only tweak the wording

<AWK> My inclination is to view this as a design principle, but may just need to understand the intent

JF: support and motivate... how can we measure this?
... support this as a goal, but how for instance do we measure knowledge gaps?
... not sure we can have a measurable state

JS: yes we can, maybe need to reword

JF: we hope we will motivate companies

<JF> +1 to AWK

<JF> I'd like to see the re-write first

AWK: in survey people agree, but questions around measurability are not competely clear yet
... good requirement, but may needs some tweaks

SL: made note to make it more clear

<laura> +1 to AWK would like to see edits for this one (and any others) before approval.

Requirement 8

<bruce_bailey> http://www.w3.org/2002/09/wbs/35422/SilverRequirmentsReview/results#xq19

<AWK> Scope: The guidelines provide guidance for content, authoring tools, user agents and browsers, and assistive technologies. EDITOR'S NOTE: The group consensus was to avoid over-loaded terms like "content", "authoring tool" and "user agent". Given the understanding that AGWG has of these terms, we also agreed they were clear in a W3C context. We will look for better terms, but we can agree on the concepts.

requirement 8: scope

AWK: if we write only for UA guidance it would be fine, but requirements we might need now may not be clear from what we have

SL: all SC now are for authors, we want to include UA and AT guiddance
... AT here is authoring tools

<Zakim> JF, you wanted to talk about browsrs more

JF: concerned about browsers
... when WG people advocate for SC for UA makers, they have rejected good guidance

SL: we need to ask if it is feasable / usable for them

JF: a great goal but not sure to do it as requirements

<alastairc> My suggestion to start with: "The guidelines provide guidance for people and organisations that produce digital interfaces. As part of that guidance there is some coverage of browsers, authoring tools, and assistive technologies."

JF: aspirational goal will be fine, requirement may be too strict, we don't have the power, we might ask for trouble

<Zakim> alastairc, you wanted to talk about that wording from my comment

AC: big difference between coverage and spec for user agents
... agree we need some coverage if there's a gap we want to high light

<Lauriat_> +1 to Alastair's wording.

AC: distinction between guidance and a spec for UA makers

JS: thinking a lot on how to motivate UA and authoring tool makers, think we have a nice idea how to give them methods instead of forcing SC
... in theory we can even provide OS methods
... people ask why we don't offer guidance for AT, UA (and OS)

<alastairc> I think we should include them, but from the point of view of meeting a user-need whilst using a particular technology, NOT for creating a whole spec for UAs / tools.

Brooks: don't think we need to be too prescriptive
... like to see another group in the scope, and that is "users"
... like how to do personalisation

JS: we had in older prototypes, got complcated though

<Zakim> laura, you wanted to say silver should provide structure to incorporate any parts of ATAG and UAAG that the group needs to incorporate.

<laura> Good example is the exemption of the title attribute in 1.4.13: Content on Hover or Focus exempted title attribute. That was pushed to silver.

<jeanne> We are not including the ATAG and UAAG success criteria.

Detlev: WCAG is already seen as too much / too big, including more like AT / UA info makes it even bigger, like to see separation

SL: filtering might be the solution to look for, one standard is preferable
... two aspect for UA guidance

MG: does Silver define documentation requirements?

SL: not clear yet, we're discussing about it still

<Lauriat_> Scope: The guidelines provide guidance for content, authoring tools, user agents and browsers, and assistive technologies.

Katie: what does the requirement say?
... support that!

<KimD> +1 to Katie

<Zakim> AWK, you wanted to ask about what happens when a user agent doesn't support X

<Lauriat_> Suggestion from Alastair: "The guidelines provide guidance for people and organisations that produce digital interfaces. As part of that guidance there is some coverage of browsers, authoring tools, and assistive technologies."

<JF> Will we have an opportunity to see the new (revised) language?

<jeanne> +1 to Alastair's - I think it addresses JF's concerns as well.

<AWK> We will need to do a CFC on this to wrap it all up, ultimately.

SL: we'll add feedback before finalising

additional requirements

<bruce_bailey> http://www.w3.org/2002/09/wbs/35422/SilverRequirmentsReview/results#xq21

<JF> scribe: JF

SL: some of the new ideas presented included usability and testing beyond known access barriers

This is absolutely our goal, and covered under things that can be measured

SL: Andrew had some additional questions as well

AWK: not sure if the scope here covers native apps - just as controversial as authoring tools (etc.)

SL: the way we've approached this is to not claim oversight there, but will offer "guidance" and suggestions

<alastairc> It does seem like something that could come under the 'scope' requirement, but it is covered (ish) under Technology neutral.

SL: depending on how the 'app' has been built, it may or may-not apply

so that guidance *can* apply, but not obligated to

AWK: there is a difference between saying we have guidance to cover each OS out there versus WCAG 2.0's goal to be content agnostic

It's served us well, but there is still more to cover

It may be worthwile to get more clarity here

SL: one of the things that will frame that discussion is... SL started here by looking at Rich Web Apps and usability

so when we start looking at items like that, it would be more holistic, as opposed to individual elements

KHS: this is the point of being able to include the functionality of authoring tools and browsers - they are software and native apps are software too

so it's really about the functionality

AWK: the other item we could have as a requirement (or sub-requirement) - if we have methods that are the SC analog - trying to be clear and requiring that there not be overlaps would be fantastic

there are multiple times where different SC (in WCAG 2.x) becomes challenging - some issues may go in more than one place

SL: OK, I think we misunderstood what you initially meant there

we started to discuss that already under the topic of WCAG 2.x migration

not sure how to word that exactly, but agree with overall sentiment

for haviing things be clearer with less overlapping guidance

[AWK and SL agree to think about this more]

AC: if the guideline level remains (user X can do task Y), I would suspect that some things *would* appear in different processes. But we should avoid duplicating methods

AWK: final comment - lots of conversation around concept of partial support, or substantial conformance

believe it is a topic that Silver TF is well aware of - may be a detail important to add

if you have a complex site (500,000 pages [sic]) being able to say "This is fully conforming" is not realistic

when we talk about testing groups - often representative sampling (etc.) - but any *huge* site will struggle today to say they are fully conformant - we've tried to do this in the past, but worth calling out in Silver

JS: we are in strong agreement here - but we're not sure exactly how we will do this yet - have a strong idea, but it's not finalizaed yet

SL: two of the requirements allude to that (multiple ways to measure, scaled scoring) - greater focus on user-success

but we don't have a solid idea yet on how to do that, so for now we want to keep it hand-wavey

but noting the suggestion

AWK: suggest we be more aggressive with the requirement

If we don't have somthing like that, suspoect it will be a major problem

AWK: if we say conformance is based on top-ten work flows might be one way to address that

even if we don't specifically address this now

JS: I do

AWK: glad you do, but most of us don't (yet) know

JS: ben working with this for a long time, that I know the things we have solutions for, and which we don't - understand those taht are controversial\

what I want to avoid is having to return and pull something down the road - being conservative here

AWK: it is important enough that as a requirement - wouldn't want to see this move forward without that req being satisfied

thus making it a requirement

SL: we've framed a lot of the discussion around other requirments, but getting close to where AWK is

where we are is that at this time we're saying that "we the WG agree this is a requirement", and if, down the road we cannot accomplish something, at least we've done due dilligence

Less concerned about this requirement however

KHS: I think we can...

do this

<alastairc> USeful to include, possible under 3.1?

AWK: anybody feel this should NOT be a requirement?

<bruce_bailey> +1 to including as requirement

<jeanne> jeanne: I do not think this should be a requirement until we know how to do it.

<Chuck> +1 s/b requirement

<laura> +1 to include

<jpascal> 2+1 to including as a requirement

+1 for making this a requirement

<JakeAbma> +1

<Rachael> +1

<Ryladog> +1

<kirkwood> +1

<Brooks> +1

<Ryladog> */thanks Bruce

AWK: seems like it is worth drafting some language to see how it is recieved when written down

SL: seems we've got our next steps - any other items or concerns?

<alastairc> Someone testing with the guidelines should not have to test across assistive technologies to establish conformance.

AC: did have one item

not sure where this would fit in, but having a req or principle stating not having to test across multiple AT to test for conformance

AWK: to follow along - whether the seperatio of authoring tools, AT, etc. - will some have expectations that they won't have to test with AT?

assuming levels of support

SL: this would be an interesting discussion with the testing group - suspect they've discussed this as well

<Ryladog> if you use AAPI inspection tools it helps cut down on AT testing

when you start to look at *all* the tools (and i18n) - where do you draw the line?

<alastairc> It has been an assumption - just wanted to make it explicit as the focus of guidlines has shifted.

AWK: not sure where that goes...

SL: remains an open question

<Ryladog> We dont want anyone to this testing with AT does not need to be done

<AWK> Relates to Requirement 8

AWK: noting this as part of Req 8 for now

AC: wfm

AWK: if anyone has any other suggestions, now would be a good time to speak up

SL: as a summary of the summary, we've added more details and have returned to some of the comments from this group

also added 2 new design principles based on CSUN discussions

will be forwarding a new version soon

Review of WCAG 2.2 Process and Acceptance Criteria (https://www.w3.org/2002/09/wbs/35422/wcag22process2/results)

MJ: just hoping that we'll get all the support - note that we often lack numbers

AWK: agree - do not anticipate running 15 separate items concurrently - we'd run out of people - thus the idea of having different "sprints"
... we have to acknowledge that we'll need to loop back on things

if there is a new SC that has gone through the entire process, and then on a second SC we discorer a clash and we discover the need to modify the first SC, then we'll need to address that

so then the question becomes, do we create another new SC,or do we expand a current *new* SC

once things get into the editor's draft, then it is open to public comment, and we'll need to be ready to adapt to that feedback - comment repsonse sprints too

JA: mostly a coment on the sprinting process - a comment that there will be a retrospective.. say every 5 or 6 sprints we step back and make sure it works for people

want to avoid getting too deep

JA: mainly about the process - we have a theory, but does it work?

AWK: we may discover we sprint in 3 weeks because we're moving slower than anticipated

+1 to Jake

<Brooks> +1 to Jake's suggestion for retros

AWK: we should perhaps add that as a note - that every X number of sprints we do this review process - obviouslyit things are going well it will be quick, if it isn't it may not be quick...

<alastairc> E.g. Note: The group will run periodic retrospective to assess the process & progress, approximately every 5 sprints.

JA: I can draft some language

AWK: Alastairs language there looks fine too

Mike suggested a number of fixes which have been added, but there were some additional thoughts

<laura> have to drop. thanks all.

question around raking & maturity'

MG: want to be sure the information we get from the WG is quantifiable (etc.) - last time there were lots of times when we were inventing on the fly - not sure everyone was on board

suggesting a mechanism to determine a relative ranking

will allow some clarity and give the cahirs more data to work with

AWK: agree this is a challenge

with the list of SCs we've already got - we can't work on them all, even if we know they are all important

so arriving at which get focus remaisn a challenge

MG: also need some kind of ranking if we feel they are ready or not

would be more useful than having a survey ready/almost ready/needs work/etc.

this would instead give the chairs more data on queue managment

AWK: so in stpe 6, tryint to teaze out more after the 2-week sprint

the WG can then say it's ready, or it's not

MG: in Step 6, we should have something in writing that says comments will be incorporated by the larger group, so we can assess it before the second week

we previously spent time re-treading issues

MG: in Step 7 - suggesting that rather than simply objecting, we have a measurable mechanism

<mbgower> Yep, point 6 looks good now

AC: kind of hoe we have that problem... more concerned about having a stock of SC documents without enough people. If we have small gorups, it may take them more than 2 weeks, so having a backlog may be useful
... a heavier aspect of it is in step 4 in terms of small group creating the original document. suspect it will make it easier going forward, but need to stay on top of that

MG: 2 major issues last time - maturity of content coming into the review, and the other was that the review was complete
... there is more flexibility with a ranking survey than an objection or non-objection

spent a lot of time last time discussing readiness

and a lot of our churn last time was figuring that out - so if we start with a ranking of maturity it will speed the process

looking for more data to make progress discussions

suspect that with quick sprints, SC will get multiple reviews

so ranking will assist in queue managment

AWK: what I amunderstanding then is that step 7 would have an impact on re-ordering (step 5)

Is that what you are describing?

MG: ya, would rather have a survey versus a big debate on the calls

AWK: there seems to be 2 questions: is this SC and parts ready and done? and at the end of 2 weeks sprints, the hope is that some will answer yes

so it will likely be a survey for new SC "X" - wit a standard survey that measures readiness and meeting the goals

but if one or members disagrees, that is the basis of the discussion

MG: specific concern - the 2 week review will be folks discussing the issues, listen, adjust, re-write and then re-present... rather than returning to discuss it, that instead there is a survey

if the survey is positive enough, then it moves forward in the WG, else it gts sent back with no group discussion

<alastairc> JF: To clarify, we should have a weighted scale? E.g. everyone says yes apart from one person. In reality, people might be thinking 80%, 60% etc.?

<alastairc> ... So if a new criteria doesn't get past a threshold it doesn't come back to the group.

<KimD> Agree with MG, maybe rank on both maturity and importance. Something may be not mature at all and also something we all see as really important. It may help the TFs focus/prioritize their work.

+1 to Mike's idea

MG: avoids too much larger gorup churn - fi a SC, after the sprint, still does not meet a minimum thresh-hold, it goes back fo rmore work (or gets put back on the shelf)

<KimD> +1 to MG's idea

<Brooks> +1

<MarcJohlic> +1

AWK: anyone else with comments?
... seems like group are happy with this - Mike's changes seem to also have suppport, so chairs will go back and try drafting some sample surveys to look at

and then advance this to a CfC

WCAG 2.2 Success Criterion Acceptance Criteria

miked results

<bruce_bailey> http://www.w3.org/2002/09/wbs/35422/wcag22process2/results#xq4

This section was meant to just look at the requirements

<bruce_bailey> http://www.w3.org/WAI/GL/wiki/WCAG_2.2_Success_criterion_acceptance_requirements

there are a number of people who agree with Glenda's comment

<bruce_bailey> http://www.w3.org/WAI/GL/wiki/WCAG_2.2_Success_criterion_acceptance_requirements#Observations

<Zakim> alastairc, you wanted to say sorry about the bottom (un edited) bit

BB: This is based on something I worked on years ago - did a deep dive of the SC to try to document Hard, or light touch, or blocking items

<alastairc> TAble of analysis: https://www.w3.org/WAI/GL/wiki/Talk:WCAG_2.1_Success_Criteria

created a tabloe, but then never returned to it

but I noted some patterns in the Observations secitons

we could decide to ignore this, but I also think this warrants some discusssion

AWK: seems we have some discussion around that piece

likely won't resolve that today

<bruce_bailey> here is the table

<bruce_bailey> http://www.w3.org/WAI/GL/wiki/Talk:WCAG_2.1_Success_Criteria

propose to return to this next meeting

AWK: look at the suggestions and re-do thison the list

<mbgower> @Awk, I'll incorporate the feedback in the survey in my PR

trackbot, end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

02 Apr 2019

Attendees

Contents