W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

18 Jun 2019

Attendees

Present
alastairc, Raf, MichaelC, JakeAbma, stevelee, Detlev, Laura, jeanne, JF, bruce_bailey, Chuck, Jan, mbgower
Regrets
KathyW, JustineP
Chair
SV_MEETING_CHAIR
Scribe
bruce_bailey, mbgower

Contents


TPAC https://www.w3.org/2019/09/TPAC/ 

<bruce_bailey> scribe:bruce_bailey

Last chance for early bird registration price for TPAC

AC: any questions about TPAC?

bruce will not be going

WCAG 2.1 Techniques survey: https://www.w3.org/2002/09/wbs/35422/Techniques-June-2019/results

Charter Review - Silver timeline

Silver update

AC: Alastair, Jeane, and Shawn had meetinging
... last week AG members express concern with timeline

Also there were concern with conformance model, and how that impact timeline

AC: we do not have update for charter, but do have some short term milestones

Jeanne: People have concerns about conformance model, but Jeanne does not agree that unresolved parts of conformance model hold up timeline
... lack of content migration is a concern for timeline

<AWK> +AWK

AC: We want to have a few migrated SC and Guidelines to have a stress test for conformance model
... may be some extra calls to work on conformance aspect

Jeane: will be sending out participation request for people to work on part time conformance model

JF: disagrees with characterization that conformance model is mostly done
... i agree we not include a lot about silver in charter

AC: Alastair and Andrew will be working on charter edits more in next couple of weeks

<Zakim> MichaelC, you wanted to say worried about not having silver in charter

MC: understand unknows w/ Silver especially timeline
... timelines difficult in general, so especially for silver, but timelines are importat for charter

<AWK> +1 to Michael regarding having Silver in the charter, but the question about whether Silver reaches REC in the charter is an open question. I hope that it can, but understand that there are concerns being expressed.

MC: while there are concerns with Silver, but we want to move beyond an incubation approach
... Silver as a community group has not gotten perhaps as much feedback as we might like
... we need to have Silver work in Charter, so that means deliverables

AC: Agree about having Silver deliverables in charter, but pros outweigh cons

AWK: there are some concerns that W3C membership would have 3 charter w/o Silver deliverable
... 2 year charter is also a possiblitiy
... also, we only need to be on a Rec track, not have the rec out.

AC: questions?

WCAG 2.2 requirements survey: https://www.w3.org/2002/09/wbs/35422/22requirements-2/results

AC: no questions, so we will talk more about this next week

WCAG 2.2 requirements

AC: two of top four

authentic authentication and...

<alastairc> https://raw.githack.com/w3c/wcag/master/requirements/22/index.html

AC: how malueable 2.0 (and maybe 2.1) SC as we work on 2.2
... last week we had broad agreement that we had permission to remove 2.0 SC if the WG goes that way
... from Bruces (and others) prompting, we've revisited a couple bullets in the draft requirements document

JF: in terms of maleability, if we want to promote an SC from AAA to AA or AA to A is okay
... I draw line at removing individual SC because that might break backwards compatibility
... bruce gave example with 1.2.3, but we can not just take that one out because of CA and other regulatory environment

@JF what about removing 4.1.1?

AC: The reasoning could be different or technology (like automatic captioning) could be better

JF: level assignment is partially about impact to author, so putting more presure on content provider could be okay
... but for territories that do not have forced compliance, the choice in single A for a choice between captioning and audio description is important
... I don't want to remove a requirement like 1.2.3

AC: right, so that this not what 2.2 requirements document
... bruce asks about having 4.1.1 under consideration for removal

JF: removing 4.1.1 is completely different
... we can remove 4.1.1 because it automatically fixed by browse
... AC: right not a gap

<AWK> Bruce: I've tried to move the discussion for 1.2.3 is to require cc and double or single A

<AWK> ... jf has convinced me that just removing it isn't the right approach

<alastairc> https://github.com/w3c/wcag/issues/782

bruce asks people to thumbs up or down on top card

AC: jake asked about value of editing 2.0 sc
... jake not on call, requirements do not say we HAVE to spend time on 2.0, but we want to have the ability to do so if the WG wants to
... not seeing hard objections
... Jake and others concerned for taking away time from Silver

AWK: we would only go back to shuffling, we would only do so if the benefit was strongly positive
... do not want to move peoples cheese

AC: we only have three proposals for removeal or change
... so we can change backwards compatiblity a bit

<alastairc> https://www.w3.org/2002/09/wbs/35422/22requirements-2/results

<AWK> https://raw.githack.com/w3c/wcag/wcag22-requirements-update/requirements/22/index.html

Jake, are you concerned for time use, or concerns for requirments documents?

AWK: see url for latest draft of requirements

(Jake seems to be muted.)

AC: any other feedback on requiremments?

David: how far out on this?

Jake: no objections, just asking for clarification on what we are aiming for, per survey comment

<JF> +1 to Jake - let's move forward

Jake: members do not have lots of spare time, so seems like we should focus more on 2.2. and Silver and not remove stuff

AC: with andrews change, we have agreement
... updated examples are included in latest draft
... bit about accessiblity support or another success criteria

JF: i am not seeing that in draft

<AWK> https://github.com/w3c/wcag/compare/wcag22-requirements-update

<alastairc> https://raw.githack.com/w3c/wcag/wcag22-requirements-update/requirements/22/index.html

AC: check that you are looking at latest draft

AWK: link provided for track changes version as well

AC: changes to bullets are most substantive

JF: i struggle with phrasing that allows removing SC
... covers removing 1.2.3

AWK: covers removing 4.1.1

AC: it is both

AWK: we added some clarification because this time around we think it is more likely that we might remove 4.1.1

<mbgower> I think it should be "provide" The Requirements for WCAG 2.0 [wcag2-req] provides

AWK: we want to be clear though that if conform to 2.2 you conform to 2.0
... very much want to keep backwards compatibility

AC: hearing no more objections

AWK: we want to have a CFC
... for now, we can go forward with requirements document in current form

RESOLUTION: Accept requirments document as ammended

WCAG 2.2 SC reviews https://www.w3.org/2002/09/wbs/35422/wcag22reviews/results

accessible authentication

AC: link is survey responses
... we did try to get a version in 2.1, but did not quite make it in. This version is slighlty updated
... editorial comments from Jake and Alastair
... Mike asks if this authentication or REauthentication?

Mike Gower: someone must have created account in the first place

MG: person must have created account, but that is out of scope for this particular SC, and this distinction should be clear

AC: agreed, this is not covering account creation process
... we do need a note to that effect
... not hearing more substantive concern

MG: technology has matured quite a bit in the last couple years

MC: this SC is not pushing boundaries any more

AWK: i hear mike about re-authentication. I do not think we need to make decision about account creation
... signing into an account is "authentication" not generally spoken as being "REauthentication"

AC: agreed, we think we take this into consideration

AWK: John Rochford will be happy with this

<jon_avila> I agree with Andrew that authentication is better term as its different than if you were logged out which is more like reauthentication

RESOLUTION: Continue with the Accessible Authentication SC

Touch Target Spacing

<jon_avila> Presents+jon_avila

<alastairc> https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit#

<AWK> @jonavila, that's a good distinction, better said than my mumbling!

AC: google doc for this from mobile task force
... a few comments, including one from Jake with concern for testing
... percentages in SC are problematic
... metrics on flexbox might be tricky

Jake: this could be a blocker because units need to measured with CSS pixels
... without CSS pixels, not testible in practice
... w/o CSS pixels, measure vary from device-to-device

<JF> With a test process like Jake described, it simply does not scale

AC: with mobile devices, can translate percent to CSS pixels, but testing something that has so much flexiblity from resizing is problematic

Jake: inspector will show percentage and width and height but not all the variable possibilities

<Zakim> mbgower, you wanted to say does zoom cause any complications on the measurements?

Jake: can only measure visually, way too complicated, if SC does not use CSS pixels

Mike: i am not sure that zooming the browser would effect measurements?

AC: viewport width would change from zoom, so that could effect other things, and everything needs to tested again

<jon_avila> When you zoom in on desktop you effectively change the viewport width

Mike: so can use CSS pixel sizing even when you want relative space to the various windows?

AC: yes, ccs pixels allows the relative size and reflow

DM: testing questions need to be resolved

AC: agreed, we might be over thinking this, but we have Jake with us, and he has concerns
... talked to tech from Amazon about where you pick up edge of link?
... is the edge to the link or the character or space next to last character?

Jake: it is 8 pixels from edge

AC: Okay then, does it make difference to user from 8 to 0 if there is 4 pixels padding when the space and target is bigger?

Jake: interesting

AC: we need more clarity in Understanding. Goal is for space with touch target.
... testing aspect is biggest question with the SC

Jake: agreed, if this is not 100% solid, we are not done with SC

JF: agree, gives example with need to test using Photoshop? that would be crazy

<Zakim> AWK, you wanted to point out the process for SC approval

AC: had some try with javascript test that put a visual outline around everything
... this seems more complicated than that

AWK: my question (from survey) is: How does this align with guidence for iOS and Android?
... i would remind that we require implementations for SC to get into editors draft
... we do not have this issue describe well enough

AC: testability main issue. any other issues

RESOLUTION: There are questions about the testability that need further work

<mbgower> scribe: mbgower

WCAG 2.1 Techniques, 1st question only. https://www.w3.org/2002/09/wbs/35422/Techniques-June-2019/results

AC: This is a technique for Device Motion Actuation
... Jake found the example didn't work. It was fine for me.

Jake: It worked with chrome but not safari

AC: ON iOS? I though they used the same engine.
... Patrick made some relatively minor wording changes

<alastairc> https://github.com/w3c/wcag/pull/669

AC: Any other questions or objections?

<alastairc> https://raw.githack.com/w3c/wcag/tech-general-motion-sensor-alternative2/techniques/general/device-motion-sensor-input.html

AC: This is one technique that got combined because of comments at CSUN.
... Last time it got reviewed, it was suggested to split them.
... Any objection to publishing?

RESOLUTION: Accepted as amended

AC: The 2-colour focus indicator is next in the queue next week.

WCAG 2.x issue resolutions, 1-5 only https://www.w3.org/2002/09/wbs/35422/Tech_Und_survey/

AC: This is github queue clearing, so hopefully these will be straightforward
... This is Bypass Blocks benefits

RESOLUTION: Accept as amended.

Public comment: Security implications of autocomplete

JF: I thought we had addressed all the public comments on the security of autocomplete

AC: I think we discussed but never responded. It came in at the last minute

AWK: It came in in June 2018.

<alastairc> https://github.com/w3c/wcag/pull/784/files

JF: I'll have to go back and check my notes. I remember getting comments from Mallory and Jove. I remember commenting to disprove their concerns.

AC: I rephrased the answer that was in github and put it in the securities section of the Understanding document
... I just realized the PR wasn't clear in the survey
... Blast.
... PR 784 shows the update, basically saying the same thing from the comment.

<AWK> line 35 - "organisation"

RESOLUTION: Accept PR as amended

3. SC note and understanding update: Orientation (Issue 416 / PR 724)

<alastairc> https://github.com/w3c/wcag/pull/724/files

<alastairc> slight change to the note

AC: everyone approved, but it's useful to note we will have a minor erratum to get it in, which is to change the note on Orientation very slightly

RESOLUTION: Accept PR 724

Public comment: Adding weight/typeface to the contrast test (Issue 665)

AC: There are a few things to do with font attributes (weight, etc) and how they affect contrast.
... The proposed to say 'yeah there's an issue, but it is difficult to test consistently'

Andrew: My background is in the video/film industry.

AC: He's possibly our most active contributor in github, so welcome.

<Detlev> voice breaking up, can't understand a thing

<david-macdonald> choppy

Andrew: I'm grabbing empiral evidence on how people use the web and are affected by some of this.

Sorry, I am unable to make out enough to transcribe

AC: We process all the issues that get into github. This one I added so we had a place to track it. There were lots of comments after the proposed response, but I wanted to indicate 'this is what our understanding is'
... Until we have a means to assess typefaces and their contrast...

<alastairc> https://github.com/w3c/wcag/issues/665#issuecomment-490086522

AC: Of the people who looked at it in the survey, most were happy with the response.
... Jake noted he didn't think it would be resolved any time soon.
... Bruce responded about possible SCs to allow users to avoid fonts

Andrew: Every font creator has their own ways of measuring them, and none of them have anything to do with accessibility.

<JakeAbma> already provided some info at https://github.com/w3c/wcag/issues/341 also with examples

Andrew: One foundry could have a completely different contrast and size relative to another foundry, with the same font.

<JakeAbma> also see: https://github.com/w3c/wcag/issues/341#issuecomment-396629013

Andrew: There is a limited relationship but no standard. i was working on coming up with a usable metric.
... They looked a dark and light pixels within a bounding box.

<Detlev> can't understand a thing

Andrew: But even in Times New Roman, the stroke on the right side of the capital is much heavier than the one on the left side

AC: You may want to try hanging up and dialing in again. You are very hard to hear.

BB: I'm hearing Andrew say there is no traction in coming up with a metric. That was my sense from the thread, and I'm a little surprised by that.

<alastairc> ak br

<Zakim> bruce_bailey, you wanted to ask andrew about fonts

BB: There are so many people who have measured legibility and readability.

Jake: I did research some time ago. One of the biggest issues is a company takes an existing font and then they adjust it a little bit.
... There is a lot of variation in existing known fonts. Even when you go a bit smaller, with antialiasing it is very difficult to measure.
... We would like to have it, but it's not possible specifically with the fonts out there.

AC: One of the things Andrew mentioned was providing a value to measure density.
... So Times-New Roman could go in the values table. One could use the calculation. But there's nothing to use right now, which is more or less what the response says.

<bruce_bailey> even "font density algorithm" might be close enough for our needs

<AWK> Seems like if we could define a way to require that users can select their own font we could avoid a lot of the challenges.

<Zakim> bruce_bailey, you wanted to ask about font substitution algorithms

AC: I don't think Bruce's comment takes away from the basic viewpoint that it needs more work.

BB: PDF documents go through a substitution table. Any font in those substitution tables would be 'good'. It's the terrible fonts we need to be alerted to.

AC: What would be the requirement on the author?

<scribe> Unknown: This goes around to the text spacing question.

<AWK> s/unknown/Jon Avila

AC: In terms of this comment, Bruce are you happy to have that comment as the proposed response?

BB: Fine.

<bruce_bailey> i agree that catching use of oramental fonts might be enough

RESOLUTION: Accept proposed response

Andrew: I managed to reconnect.
... This is the kind of thing where Google and Adobe could join together with us perhaps to make a standard that others could follow along with. They have enough weight behind them.
... Maybe we can reach out to them to come up with a way to measure font size and contrast. Other foundries could step in line.

AWK: Did I understand you go by Andy?
... We've got this marked as WCAG Next. I think we can mark this as deferred. This needs ongoing work.
... I'm happy to set up a meeting with Adobe's research group.

AC: It's already marked as deferred so we can continue

Public comment: Maximum contrast (Issue 675)

<alastairc> https://github.com/w3c/wcag/issues/675#issuecomment-490564820

AC: I put in a comment essentially saying we don't have a maximum contrast level.

Andy: I"m looking at this as part of the other research I'm doing
... higher contrast potentially makes it more blurry, not less.

AC: This is a deferment issue, so if everyone is still happy with that response...
... Any objections

RESOLUTION: Accept response to 675

AC: Does anyone have any 2.1 techniques they're working on? Jake?

Jake: I have one on orientation
... If you like you can go through it.

AC: Excellent, we'll get that one for next week.

Jake: We still have some wording to do for the Understanding document.
... It's not so much about device as width and height

AC: In the future put the examples in the same branch as the technique

David: I had a question about one on down-event from a couple of weeks ago.

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

s/year ago/weeks ago

David: I didn't have the spreadsheet in front of me.

AC: I'll have to look up the one you did.

David: It would have been a cancellation

AC: The bottom one marked as approved is the one you did recently
... Would anyone like to vounteer for a technique?
... Character Key shortcuts could do with some work.
... There is probably an easy one there.
... On having to remap shortcuts
... We'll have the charter discussion and other techniques for next week. And issues to review.

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Accept requirments document as ammended
  2. Continue with the Accessible Authentication SC
  3. There are questions about the testability that need further work
  4. Accepted as amended
  5. Accept as amended.
  6. Accept PR as amended
  7. Accept PR 724
  8. Accept proposed response
  9. Accept response to 675
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/06/18 16:53:12 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/charger/charter/
Succeeded: s/possitive/positive/
Succeeded: s/MC asks/Mike asks/
Succeeded: s/might be trick/might be tricky/
FAILED: s/unknown/Jon Avila/
Succeeded: s/NEXT TOPIC/TOPIC/
Succeeded: s/I'mdoing/I'm doing/
Succeeded: s/heighth/height/
FAILED: s/year ago/weeks ago/
Succeeded: s/years ago/weeks ago/
Default Present: alastairc, Raf, MichaelC, JakeAbma, stevelee, Detlev, Laura, jeanne, JF, bruce_bailey, Chuck, AWK, Jan, mbgower

WARNING: Replacing previous Present list. (Old list: Chuck, AWK, alastairc, Rachael, JakeAbma, Raf, Jennie, JF, stevelee, MarcJohlic, Detlev, Laura, MichaelC, Fazio, SteveRepsher, Katie_Haritos-Shea, johnkirkwood)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ alastairc, Raf

Present: alastairc Raf MichaelC JakeAbma stevelee Detlev Laura jeanne JF bruce_bailey Chuck Jan mbgower
Regrets: KathyW JustineP
Found Scribe: bruce_bailey
Inferring ScribeNick: bruce_bailey
Found Scribe: mbgower
Inferring ScribeNick: mbgower
Scribes: bruce_bailey, mbgower
ScribeNicks: bruce_bailey, mbgower

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 18 Jun 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]