Accessibility Guidelines Working Group Teleconference -- 19 Dec 2017

<AWK> Chair: AWK

<david-macdonald> presnt+ david-macdonald

<Glenda> scribe: Glenda

Interruptions (minimum): https://www.w3.org/2002/09/wbs/35422/interruptions-minimum-review/results

AWK: Reminder, we have a 3 hour call on Thursday so we can finalize these SC in the little time we have left before CR.
... Thanks for everyone’s dedication

<lisa> https://www.w3.org/WAI/GL/wiki/2.2.7_Revision#

<lisa> also had A mechanism is available to postpone or suppress non-essential interruptions unless are part of the workflow or are initiated by the user or involve an emergency. Note: Error, success, and warning messages; timeout notifications; changes of context that are part of the workflow sequence; suggestions about the users intent such as as autofill and auto-correct; and live updates when the purpose of the content is monitoring are considered essential. i

AWK: reviewing results of survey and comments.

<bruce_bailey> I am happy with edit

<AWK> https://www.w3.org/WAI/GL/wiki/2.2.7_Revision - has multiple versions

Lisa: have been addressing all the comments and issues that came in (prior to today). Just a couple of decisions we need to make. We have 2 versions posted here: https://www.w3.org/WAI/GL/wiki/2.2.7_Revision#

<lisa> A mechanism is available to postpone or suppress interruptions and changes in content unless they are essential to usage or meaning of the content, are initiated by the user or involve an emergency. Note: Error, success, and warning messages; timeout notifications; changes of context that are part of the workflow sequence; and live updates when the purpose of the content is monitoring are considered essential. Definition: interruptions: Secondary information, pop-

<lisa> A mechanism is available to postpone or suppress non-essential interruptions unless are part of the workflow or are initiated by the user or involve an emergency. Note: Error, success, and warning messages; timeout notifications; changes of context that are part of the workflow sequence; suggestions about the users intent such as as autofill and auto-correct; and live updates when the purpose of the content is monitoring are considered essential. i

Lisa: are there any problems still outstanding, or is one of these verions able to get consensus

<Alex> in the SC text?

AWK: should we change the word “content” to “context” in the proposed SC text.

<lisa> non-esential interruptions: Secondary information, pop-ups, overlays or actions that are not part of the workflow sequence or the key purpose of the content.

Mke_Pluke: worried about secondary info related to the workflow. some interruptions are important, others not, but it depends on the users intent. How does the system know my intent?

Lisa: we can piggy back off the title of the page…as the main purpose of the page

<lisa> Web pages have titles that describe topic or purpose.

<AWK> Glenda: really think that in one example of a booking web page the interruption is related to the booking of a ticket and would be exempted.

<Zakim> gowerm, you wanted to say insight from the Status Changes grunt work may help inform this discussion

<lisa> non-esential interruptions: Secondary information that does not directly relate to the contents topic or purpose, pop-ups, overlays or actions that are not part of the workflow sequence or the key purpose of the content.

<Zakim> Joshue, you wanted to ask how (and why) we need to get around the definition

gowerm: some of the work we did on status changes might help us here. We isolated it down to the biggest problem (when from “change of content” and focused down to just “change of status”). We lost a lot..but it allowed us to create a clear SC that can be understood and tested and met. So, recommend we focus this one as well. (on the biggest problem).

Joshue: +1 to what gowerm just said
... I think we need to make this tightly focused for clarity.

David: Better without “changes of content”. I was disappointed we weren’t able to solve all the problems…but I recognize that “status changes” was clear, concise and testable.
... What about an inerruption like a pop-up that asks “do you want to sign up for our email blast?”, is that going to be an interruption? Clients will be mad if we block that.
... Is the email signup essential for the client…to be able to sell more stuff to users?
... If a pop-up blocker works on blocking the “sign up for email blast?” interruption…then that would be sufficient.

AWK: do people feel like your comments and concerns have been addressed?

<Brooks> +1 to David's considerations

<lisa> non-essential interruptions: new content, pop-ups, overlays or actions that are not part of the workflow sequence or are not directly relate to the main topic or purpose of the content.

<lisa> non-essential interruptions: new content, pop-ups, overlays or actions that are not part of the workflow sequence or does not directly relate to the main topic or purpose of the content.

jason: relating it to the purpose of the content is the right approach, but it won’t solve everything. If I’m in compose mode in email, but I’m interrupted by a “new email arrived”…is that an allowed interruption, or not? Perhaps we need to develop a definition of egregious cases. Make sure we don’t create something that will cause a lot of disagreement in evaluation.

<lisa> i think we all agree to lose changes of content

Jason: want more precise definition of distracting interruptions. Stay away from unclear realm of things that are “somewhat related”…but are they enough? Lisa’s latest version will need editorial clean-up.

<lisa> non-essential interruptions: new content, pop-ups, overlays that are not part of the workflow sequence or do not directly relate to the main topic or purpose of the content.

Lisa: we’ve agreed to drop “change of content”. We can close this discussion.
... Only outstanding issue is definition of interruptions.

<AWK> Lisa, what is the latest SC text?

Lisa: The title of the page (from WCAG 2.0 A) already defines the purpose of the page. So we are not adding more ambuiguity.

<lisa> non-essential interruptions: new content, pop-ups, overlays that are not part of the workflow sequence or do not directly relate to the main topic or purpose of the content.

AWK: can you put in the latest version of the SC text?

<gowerm> FYI, SC for 2.4.2 Page Titled is Web pages have titles that describe topic or purpose. (Level A)

<lisa> latest sc text: A mechanism is available to postpone or suppress non-essential interruptions unless are part of the workflow or are initiated by the user or involve an emergency.

<lisa> definition for non-essential interruptions: new content, pop-ups, overlays that are not part of the workflow sequence or do not directly relate to the main topic or purpose of the content.

AWK: can we just define interruptions?

+1 to defining “non-essential interruptions” as cleaner

<jasonjgw> I prefer "unnecessary interruptions" or moving "essential" to one of the explicit exceptions.

<bruce_bailey> The bit about “part of the workflow” is in the SC and the definition

Mike_Pluke: what does workflow sequence mean? not defined. How will that be tested?

<lisa> we can lose the workflow sequence

<Zakim> gowerm, you wanted to say workflow is tough to interpret

gowerm: designed workflow versus users intent of using the workflow?

David: I think of overlay and pop-up as ways of delivering content. I’m concerned that overlays and pop-ups are not always non-essential.

<lisa> A mechanism is available to postpone or suppress new content, pop-ups, overlays that do not directly relate to the main topic or purpose of the content unless they are essential orinitiated by the user or involve an emergency.

David: I want to exclude pop-ups that are on-page load. To provide a site to let you know about a sale, or encourage you to sign up for an email list. User has not started their process.

<Brooks> Are television commercials "non-essential interruptions," or are do they serve an integral part of a system that provides content/functionality in exchange for a short bit of the user's attention?

<lisa> no, only if it is a pop up, or new content

<AWK> Lisa's latest: A mechanism is available to postpone or suppress new content, pop-ups, and overlays that do not directly relate to the main topic or purpose of the content unless they are essential, initiated by the user, or involve an emergency.

<lisa> ie advertizments that interup the user

Alex: many websites depend on advertising. This would have a negative effect on advertising. Would this SC make it impossible for some business to survive (because they will loose too much ad revenue). Do we want to ask sites to decide between accessibility and their ability to stay in business?

<AWK> A mechanism is available to postpone or suppress new content, pop-ups, overlays that do not directly relate to the main topic or purpose of the content unless they are essential, initiated by the user, or involve an emergency.

<AWK> A mechanism is available to postpone or suppress new content, pop-ups, and overlays that do not directly relate to the main topic or purpose of the content unless they are essential, initiated by the user, or involve an emergency.

Lisa: do we need to define “new content”?

<AWK> Glenda: response to what Alex says - let's let advertisers advocate for themselves.

<AWK> ... many of the interruptions are not helping advertisers

<AWK> ... these changes may help them increase their click-through rate

<gowerm> A mechanism is available to postpone or suppress new content that does not directly relate to the main topic or purpose of the content unless it is essential, initiated by the user, or involves an emergency.

James: disagree with Glenda. Advertisers are not watching WCAG. Ads are distracting you and interrupting you. Ads is how TV survives.

<Ryladog_> +1 to Glenda's comment to let the community decide - our job as Accessibility standards builders is to suggest supports to improve the web fr persons with disabilities. Not to support advertizers

Glenda: I am clicking on ads that are not interrupting me and buying things based on those ads. But when they sneak attack me…I will not buy from them.

<Brooks> +1 to David, Alex and James: We can't exempt users from being exposed to distracting advertisements on the web...focus of this SC needs to be much tighter.

Jason: give people the ability to postpone interruptions early on.

Lisa: we are working on mechanism for user settings…to support personalizations (for future solutions).
... we could allow a subscription model to pay to not be interrupted. Subscribe to stop ads. This could be a sufficient technique.
... people with problems with working memory…are truly prevented from using the web when they are interrupted. Sticking point is based on advertisers. This is a guideline for people with disabilities. Let the legislatures decide if this is bad for advertising.

AWK: we recognize that this is a problem for users. This discussion is based on practical realities.

Kathy: I agree that this is a significant impact to business. We are not going to be able to get rid of ads. We need to think about ways that we can make an SC that is reasonable for business.

<kirkwood> +1 to Katy

Ryladog: we already support distracting advertising. We were successful with implementing flashing (at a certain rate). This is our responsibility. We need to make it possible for busines and advertisers. We cannot just walk away from this.

<Zakim> JF, you wanted to say paywall sites and others protest when ad-blockers are present already

+1 to Katy from goodwitch

<lisa> +1

JF: currently paywall sites that are protesting users how have adblockers
... agree with Kathy, Alex and others. Concerned that this will become and SC that people will ignore.

<Ryladog> We do alraedy support 'distracting advertisements' that meet a certain flash paradigm for photosensitivy because it prevents them from using the web. If the 'distracting advertisements' pop-ups prevents a person with cognotive issues from using the web - then I think we need to do the same thing here.

<lisa> so lets think of a solution

<Ryladog> But the US didnt put in that waiver

<Zakim> gowerm, you wanted to say this is shorter and I think loses nothing: A mechanism is available to postpone or suppress new content that does not directly relate to the main topic or

<Ryladog> test

<Ryladog> Again, the US didnt put in that waiver

gowerm: this is a balancing act. I don’t see this as massively restrictive. Websites can chose to not meet this SC, but many will and this is not that high of a bar.

+1 to what gowerm is saying. Let’s do this!

<lisa> A mechanism is available for people with disbilities to to postpone or suppress new content that does not directly relate to the main topic or purpose of the content unless it is essential, initiated by the user, or involves an emergency.

JF: suggest moving it to AAA

<AWK> -1 to adding "for people with disabilities"

Lisa: proposing new wording: “A mechanism is available for people with disbilities to to postpone or suppress new content that does not directly relate to the main topic or purpose of the content unless it is essential, initiated by the user, or involves an emergency.”

<jamesn> -1

<JF> -1 to adding "for people with disabilities"

<JakeAbma> -1

<david-macdonald> -1

<gowerm> -1

<alastairc> This would open up a whole lot of other feasibility issues.

AWK: we need to move on.

<lisa> Can other people try and think of a way to adress this issue?

RESOLUTION: Leave open

<jamesn> scribe: jamesn

Accessible Authentication: https://www.w3.org/2002/09/wbs/35422/Accessible-authentication-review/results

AWK: lets see where we are

This SC is testable, implementable, and beneficial to people with disabilities - ready to go. - 5

This SC has major problems that need to be addressed, a discussed in the following comments. - 6

<AWK> Wiki page: https://www.w3.org/WAI/GL/wiki/2-2-6_Revision

AWK: there is a page on the wiki

which has assitional revisions

some of the comments are:

there is a variety of comments

not going to try to summarize

JW: there was a lengthy series of concerns which summarized a lot. Best would be to review the written text

raised concerns about the interactions between the alternatives offered in the proposal

people could do the 2nd one - that would allow a Multi-factor authentication that meets the first which doesn't mee the 2nd.

not sure it was intended by the WG. Share the concerns of MG about the inadequacy of the justification. Not sure satisfactory evidence has ben produced

even though there is progress with the web authentication specification

all the implementations are experimental so could be a timing problem

it could be subsequent to a recommendation after WCAG2.1

do we want to slow down adoption until web authentication is out there

written commentary gives more details

AWK: MG had a comment

A dozen open issues, with almost no comments and no resulting changes. https://github.com/w3c/wcag21/issues?q=is%3Aopen+is%3Aissue+label%3A%7Ecomment-accessible-authentication

There has also been significant discussion in the list, with no changes to the SC language in the latest editor's draft.

AWK: also on the survey - What this SC really says is that the authentication process or reset process cannot rely on recalling or transcribing information, with a couple of exceptions.

we could simplify it as if the exceptions apply then it doesn't rely on transcribing info

Bruce is concerned about essential

DMD: don't know if we have solved the security issues yet

<lisa> we did an audit and i sent on the results

it is a problem in general that security experts are trying to solve. I am uncomfortable without a security expert being closely involved

it is very sensitive when we talk about security

<jasonjgw> In my survey response, I gave an option of moving the "transcribe information" requirement to level AAA.

LS: before people object I have sent in a flurry of emails some things people need to know

have sent to web authentication asked them explicitly are there any issues

also had a very early draft discussed F2F. Did an accessibility audit with independent people

tried to address concerns. Then the web authentication specification - people think it is not mature.

mozilla, edge and chrome have implementations

they want to go to CR within a month

so this is the obvious way to meet this SC in the most secure way possible. If people want to do it in a simple way

they could have a FB login

can recommend to allow passwords - recommend something that is secure enough

if we can have a technique

MFA there are different ways to use it. Copying text from an SMS is not secure.

you can use multi factor using bluetooth.

Q codes lots of ways

AC: answer some of these

I sent an email to the list trying to summarixe

3 scenarios to worry about

username/password

Multi-factor authentication (1-time password generators)

last and most difficult is the email provider

in the simple case there are reasonable techniques.

Email reset, a magic link which can be sent

2 factor - this is where things get unstuck

web auth abstracts away the 2nd factor. The reason I don't think it is ready is confusion about what implementations mean

Chrome has released. Edge and FF have an implementation but it is not released

that worries me (quite a lot)

<lisa> see https://wiki.mozilla.org/Security/CryptoEngineering#Web_Authentication) and looking though the wg minuets it seems Edge also has implementation (https://blogs.windows.com/msedgedev/2016/04/12/a-world-without-passwords-windows-hello-in-microsoft-edge/

there are other methods, Bluetooth, QR codes etc. but there are not standardized libraries for this kind of thing

in 2FA we are very reliant on web auth

we also need to account for password managers. That becomes a user agent requirement. Not sure there is anything we need to do to tell people to use password managers

the new version is scoped to reauthentication

can log in once with username/password and 2nd Factor. but at reauthentication it replaces a factor

we need to rescope based on password managers

MP: not a very specific comment. this is a very significant scope on the amount of the internet which is impacted. I want to put in context that being more critical. we are going to have to take the draft SCs to put into a standard pre WCAG 2.1

<alastairc> Lisa, that MS page says: "We have implemented our APIs with the ms-prefix to indicate that these APIs are very likely to change in the future. We’ll continue to update the APIs in future releases as the standard finalizes – so be sure to watch for changes."

<Zakim> gowerm, you wanted to say that asking questions may not be the same as having someone attending and hearing the concerns

<lisa> we did change that skope

MG: getting back to the comments on having security experts review things. Rewording this as reauthentication solves all of this. At some time you needed to use a password. So reauthentication helps a lot.

<AWK> James: the second factor is where there are significant problems

<alastairc> Link to my comments: https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/1037.html

<AWK> ... we can't rely on FB for authentication due to privacy concerns

<AWK> ... Oracle security wouldn't allow

<AWK> ... WebAuth will solve a lot but not ready yet, no standards for bluetooth and QR yet

LS: lots of problems with login with facebook

it is a cheap and nasty way of doing things

we all agree that web authentication stage. They may leave CR before us. They are leaving CR according to their schedule. Doesn't seem to be this huge lag. Chrome for web authentication works.

why do people think it is not mature

they have published that they have builds - they have done enough of the implementation.

AC: it is not released
... they are behind flags

which means you have to customize things

<Alex> i have to look

AC: in the link it says it is behind a prefix

LS: we think it will be available but for now we would be relying on the fact that it would work in chrome

AC: in terms of standardized way of doing 2 FA there is no standardized way of doing things
... if you take web auth out. You have standardized libraries - the rest require to create a phone app. Or use other things

most of the others don't have an API to the browser

there is loads of hardware stuff but you don't access it through the browser

2FA is dependent on the phone not the browser. If you are authenticating through the browser you need a standardized way of doing this

LS: we have a thing - you are saying we are not going to get though CR unless edge/FF get a real implementation

we have in the requirements that we are going to have this to get through CR

no need to pull somehting out when we are 80-90% sure we will have the technology

even if everything you were saying was 100% robust - I think will agree - we could have an at-risk to ensure there was specific implementation

AC: I don't mind putting it at risk based on those things

me the main issue is accounting for password managers

LS: I disagree that it is a problem for CR. We have our criteria
... I think we can shelve until CR
... do you think we can handle password managers as a technique
... some people are using patterns rather than passwords

AC: are they using it instead of passwords or as well as passwords

Mike Pluke: as well as passwords

<alastairc> Mike was saying his example was as well as passwords.

<lisa> but it is required step

<alastairc> When do we have to test for mutiple implementations?

JW: i think it is partly a timing issue with web authentication. Do you want to delay implementation until content developers or policy setters determine that the web authentication specficiation is implemented or available on a large scale

<AWK> @alastair - to exit CR

the issue of transcribing information is still open.

<alastairc> FWIW, I've done a reasonable amount of testing with people with cog issues, and I buy the need. It's super hard for some people.

I don't think I could fairly or accurately convince anybody that there is a group of people who can't transcribe from 2nd factor and can do everything else they need to do on the web site

people want to get away from passwords and web authentication is a way to get there

do we want to slow down wcag21 conformance until that is available or not

LS: what is the upper threshold on what is reasonable to ask on how many numbers

we do not have that data

so that is the piece we don't have

when passport managers are not working people can't use things

when we asked people in COGA if we should scope out 2FA there was resounding no

I am again locked out of my bank account

it does start to get upsetting

we didn't ask that question for other groups

that is saying should coga be in scope

hopefully that addresses those issues

AC: I wouldn't count it as research

have done testing

I can imagine it is next to impossible to transcribe 6 numbers etc, or pick characters out of a word etc.

make it reliant on another implementation of web auth. I think it is worth continuing with

have work to do to rewrite to do that

<AWK> https://www.w3.org/WAI/GL/wiki/2-2-6_Revision

AWK: take into account password managers

<alastairc> Latest: https://www.w3.org/WAI/GL/wiki/2-2-6_Revision I can have a go tomorrow.

current version doesn't account for them

LS: can we address password managers as a technique

it is a better way to do it as need to test your website with a password manager

AC: I put a proposal in an email. There is a different content requirement. If have a standard username/password field it should work

it is nothing to do with the transcription

<Zakim> gowerm, you wanted to say what about a Password Manager (non web)

MG: going to raise the topic a standard password manager

i would consider it AT in this context. If there is a restriction then otherwise it is removing a requirement to remember passwords from a user

<alastairc> My suggestion was: "Assisted Authentication: User interface components which gather authentication credentials do not prevent automatic entry."

LS: If there are password managers which work with a fido device for example

then that is a valid technique so long as your website works with it

MG: not actually a technique. It is a standard device

LS: with the wording we have we haven't barred on it.

MG: effectively what we have is that a certain part of the list we are asking web authors to do

if need to rely on a password manager> If the password manager solves the problem then do not allow people to have a congnitive load on strings that are sent

that was something that could clearly be done by authors

LS: maybe we can have a call to try to reword it

RESOLUTION: Leave open

AWK: not going to make progress on animations

Signing people up for open issues

<AWK> https://github.com/w3c/wcag21/issues?q=is%3Aopen+is%3Aissue+label%3A%22Dec+WD+Comment%22+no%3Aassignee

AWK: 9 with no assignee

<AWK> Draft responses on this wiki page: https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues

What we are doing is coming up with draft responses on above wiki page

<alastairc> I've assigned myself the graphics contrast one. It's an easy one...

<gowerm> I can take hover or focus

<lisa> can somone put on irc what i took

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

- DRAFT -

Accessibility Guidelines Working Group Teleconference

19 Dec 2017

Attendees

Contents

Interruptions (minimum): https://www.w3.org/2002/09/wbs/35422/interruptions-minimum-review/results

Accessible Authentication: https://www.w3.org/2002/09/wbs/35422/Accessible-authentication-review/results

Signing people up for open issues

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output