Accessibility Guidelines Working Group Teleconference -- 12 Oct 2017

<AWK_> +Rachael

<AWK_> Implementation survey: https://www.w3.org/2002/09/wbs/35422/WCAG21_impl

<AWK_> Scribe: Jason

<jasonjgw> scribe: jasonjgw

<AWK_> https://www.w3.org/2002/09/wbs/35422/WCAG21_impl/results

Implementation process (https://www.w3.org/2002/09/wbs/35422/WCAG21_impl/)

<AWK_> https://www.w3.org/2002/09/wbs/35422/WCAG21_impl/results

AWK summarizes the results of the survey on CR exit criteria.

<AWK_> For wCAG 2.0: https://www.w3.org/WAI/GL/WCAG20/implementation-report/

AWK: explains the role of CR exit criteria and the requirements of the W3C Process Documents - that there must be two independent implementations. The survey links to the implementation report for WCAG 2.1.

The exit criteria for WCAG 2.0 are our starting point, but comments have been received on the survey.

At least 4 or 5 participants have suggested that requirmeents 1 and 2 of the WCAG 2.0 success criteria shouldn't be looked at for 2.1. We needn't show cofnormance to success criteria inherited from WCAG 2.0, but only that the new 2.1 criteria (those added in 2.1) can be implemented.

There must be two implementations of each SC that we add in 2.1. In addition, there must be assistive technologies for which we have documentation (of accessibility support) and documented techniques for implementing the new success criteria.

AWK notes consistency among several of the comments in the survey. He asks whether anyone thinks we need to find new implementations for the 2.0 SCs as opposed to focusing entirely on the 2.1 SCs.

Mike: there might be ramifications in relation to the 2.0 SCs of implementing them in the context of 2.1, so he isn't sure we should exclude 2.0 SCs from the implementation process.

Alastair: we shouldn't focus on the 2.0 criteria unless there are GitHub issues suggesting overlap with the new SCs.

It shouldn't be necessary for the exit criteria, but as part of the process we should address such overlap

AWK: suggests we can identify 2.0 SCs that may incur impact as a result of the 2.1 additions, and deal with such issues in the CR process.

<laura> +1

MichaelC: largely agrees with other comments, but wishes to separate the formal requirements of Candidate Recommendation from other testing that we ought to do. He suggests dealing with overlap or dependencies among 2.1 and 2.0 SCs if possible prior to CR.

<alastairc> sounds good, +1 to Michael's comments

However, doing so should not be a formal requirement of CR exit criteria.

Bruce: the primary focus should be on two implementations of the 2.1 SCs.

Responding to a question, MichaelC clarifies that basic implementability is the focus of CR, not public support or widespread implementations.

AWK: we should be able to find two Web sites that meet each of the new success criteria. He notes that it's more challenging a goal to reach when browser implementation is required - which it isn't here.

<Detlev> can't find the link to the Webex meeting - would someone mail it to me?

MikeG agrees with MichaelC's approach.

<Detlev> @AWK - ah great

AWK: survey respondents suggested we need not adhere to teh 2.0 CR requirement of 10 implementing Web sites. He asks whether this requirement is necessary, or whether two implementations of each SC are sufficient.

MichaelC: suggests tehre should be testing of cofnormance levels covered rather than by individual success criteria. He does not think we should adhere to a specific number.

(of implementing Web sites).

AWK: the question is as to removing items 1 and 2 from the WCAG 2.0 exit criteria - no need for 10 implementations or for demonstrating partial conformance.

Detlev: thinks less effort should be devoted to evaluating at Level AAA.

He considers we need to show that we can still conform to 2.0 SCs - those which are now part of 2.1

<gowerm> +1 agree #2 seems pretty odd

Steve: interprets the partial cofnormance requirement as needing to show taht what we say in WCAG about partial cofnormance works

It's unclear whether we need to demonstrate, e.g., Level A only.

<Zakim> MichaelC, you wanted to say we need conformance level examples that collectively cover all the added SC and to say we need AAA and to see partial conformance not needed because not

MichaelC: we don't need to test A as it's covered under AA - however, we need to identify situations in which one can conform to one success criterion but then not to another at a different level (e.g., an SC from A and another from AA - or from AAA).

We don't need to perform a partial conformance claim test, as this is unchanged in 2.1.

<Detlev> +1 to Michael

<steverep> +1 to Michael C = my opinion exactly

Alex: especially in relation to zoom and adapting text, we need to look for issues of concurrent implementation of both SCs.

AWK: considers taht there may be other examples of interdependencies.

There is discussion of whether zoom text and color contrast requirements may interact.

Poor contrast may become more perspicuous at scale (e.g., an icon that only appears due to a responsive design when the text is enlarged).

MichaelC: this is a case where we should separate CR exit criteria from best practice evaluation. However, responsive design and other issues should be acknoweldged and added to an understanding document - they should be kept out of CR exit criteria.

Brooks: do we have sites that might pass a 2.0 SC but then not pass due to changes made to implement a new SC.

<Zakim> gowerm, you wanted to say Consistent Navigation is another SC where the new Zoom could cause breakage.

<AWK_> Brooks: one example is that a site that is zoomed will have a larger area of flashing content

MikeG: consistent navigation requriements are potentially affected by zoom, reflow and responsive design. He suggests we need to assess some potentially cofnorming 2.1 sites against the 2.0 SCs.

MichaelC: testing conformance to 2.0 SCs should not be formally required in the CR exit criteria. We can exceed the bar (of CR exit criteria) but we shouldn't set the bar higher than is necessary.

AWK: we're looking for a combination of sites that affirmatively implement all of the success criteria.

MichaelC: we only need these implementations for the new 2.1 SCs. That is, we need a combination of sites that collectively, actively meet all of the SC to achieve total coverage.

He suggests that looking for interactions among SCs should be looked for but should not be a CR requriement.

AWK: of the 2.0 exit criteria, we're interested in achieving #1 for some number of sites.

He asks wehther we should ahve, e.g., 5 sites - four at AA and one at AAA?

What should #1 say if we're keeping it?

<Detlev> +1 to AWK proposal (4 AA, 1 AAA)

MikeG: he needs to review the AAA criteria to determine how many sites are likely to be able to conform.

MichaelC: if conforming is too burdensome over-all then it's a problem that should be identified.

If we discover that Level AAA SCs are "big asks" during the CR phase, we have to return to working draft status - this should be identified before we move to CR.

Responding to a question, MichaelC identifies that we need to ensure those not involved in the working group can successfully implement. Implementation on large mainstream sites - with real-world significance - is desirable but not essential. Small sites and demonstration sites can be relied on for the purpose.

AWK: it's hard to introduce even small changes to large sites.

Katie: suggests a portion of a site could demonstrably conform.

MichaelC agrees that this is sufficient for CR testing, but the work ideally shouldn't be carried out by people involved in WCAG spec development.

AWK: exit criterion #1 for WCAG 2.0 imposes a minimum number of Web pages per site.

He asks for alternate proposals for #1 (besides 5 sites - 4 at AA - 1 at AAA).

<gowerm> +1

<gowerm> drop it

Exit criterion #2 (partial cofnormance) - AWK proposes dropping it.

No one disagrees.

<Ryladog> +1

<laura> +1

Exit criterion #3: at least two implementations of each success criterion.

<Ryladog> +1

MikeG: inquires whether (e.g., for content on hover or focus) meeting the exception is considered meeting the SC.

AWK: thinks that if the SC is met by satisfying the exception, it qualifies as meeting the SC. We need two implementations that demonstrate positively meeting the success criterion.

MichaelC: in general, an exception declares situations in whcih an SC is not applicable. For purpose of CR, non-applicability is not sufficient to satisfy the SC. The SC has to be affirmatively met (i.e., actually implemented).

AWK: Accessibility support documentation for at least two technologies.

AWK notes that this is important to demonstrating technology independence of the specification.

He suggests that identifying technologies which can meet our "accessibility supported" needs shouldn't be difficult.

<steverep> So it is a matrix requirement?

MichaelC: notes that the combination would be a user agent/technology combination.

<Ryladog> +1 to MC, to not repeat this

MichaelC proposes that we don't need to test this item, since we haven't changed the concept of accessibility support and how it operates in WCAG, whereas it was new in 2.0 and then still subject to close scrutiny.

<Detlev> +1

AWK clarifies that the working group produces the "accessibility support" documentation to show that the SCs could be met using that technology - showing how the technology supports what is necessary to meet WCAG.

<gowerm> +1 take it out; my only proviso is that it's good requiring keyboard documentation where keyboard operation deviates from standards

Steve: suggests that a less extensive matrix of technologies would suffice.

<AWK_> https://www.w3.org/WAI/GL/WCAG20/implementation-report/accessibility_support

AWK: we need two different technologies taht are accessibility-supported.

Alex: inquires which variety of HTML would need to provide the accessibility support.

<Zakim> MichaelC, you wanted to say steve may be right we need accessibility support documentation *for the new SC* and to say or maybe our SC testing will provide enough evidence

MichaelC: maybe we need to document accessibility support for the new SCs. We would try not to be too specific (e.g., to versions of HTML or what is implemented in different user agents).

<AWK_> Jason: some of the new SC, e.g. personalization

<AWK_> ... raise issues of accessibility support and we may need to document that support

<AWK_> ... because it could be changing quickly

<AWK_> ... this is similar to 4.1.2 for WCAG 2.0 because of ARIA support changing

AWK: regards jasonjgw's comments as implying some kind of technology support requirement for the new SC.

<Alex_> hard stop, have to run

AWK: techniques have test procedures and all issues have been addressed (that is, all open issues).

AWK suggests that we have agreement on everything but accessibility support documentation - at least among those of us who are on the call.

AWK proposes that we'll uncover accessibility support information as we perform CR-related conformance evaluations, but perhaps we don't need to include it formally in CR exit criteria.

<AWK_> Jason: think that focusing on the new SC, especially where they demand new technologies, and definitely related to adapting text and zoom, that the content can adapt appropriately

<AWK_> ... the ASD will provide that reassurance

<Brooks> It is important for us to consider, at some point, support the technology stack provides in support of the new SC.

<Brooks> +1 to Jason

AWK: proposes to submit a summary to the mailing list.

He requests that those with GitHub issues ready for resolution should notify Josh and label the items accordingly.

- DRAFT -

Accessibility Guidelines Working Group Teleconference

12 Oct 2017

Attendees

Contents

Implementation process (https://www.w3.org/2002/09/wbs/35422/WCAG21_impl/)

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output