<bruce_bailey> scribe:bruce_bailey
Last chance for early bird registration price for TPAC
AC: any questions about TPAC?
bruce will not be going
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?
AC: no questions, so we will talk more about this next week
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
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
<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
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?
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.
AC: This is github queue
clearing, so hopefully these will be straightforward
... This is Bypass Blocks benefits
RESOLUTION: Accept as amended.
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
<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
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
<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
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]