Meeting minutes

https://www.w3.org/2017/06/06-ag-minutes.html


Accessibility Guidelines Working Group Teleconference
06 Jun 2017

See also: IRC log<http://www.w3.org/2017/06/06-ag-irc>

Attendees

Present
AWK, Davidmacdonald, jasonjgw, MichaelC, KimDirks, Katie_Haritos-Shea, JF, Kathy, MikeGower, chriscm, shadi, Wayne, JanMcSorley, jeanne, ChrisLoiselle, Laura, Glenda, marcjohlic, Makoto, Melanie_Philipp, Rachael, Joshue108, alastairc, kirkwood, JakeAbma, Pietro, Mike, Elledge, Mike_Pluke, Bruce_Bailey
Regrets
lauriat, EA_Draffan, Detlev, Jim_Allan, KathyW
Chair
AWK
Scribe
Glenda
Contents

  *   Topics<https://www.w3.org/2017/06/06-ag-minutes.html#agenda>
     *   AGWG summer schedule https://www.w3.org/2002/09/wbs/35422/AWAG_summer_2017/results<https://www.w3.org/2017/06/06-ag-minutes.html#item01>
  *   Summary of Action Items<https://www.w3.org/2017/06/06-ag-minutes.html#ActionSummary>
  *   Summary of Resolutions<https://www.w3.org/2017/06/06-ag-minutes.html#ResolutionSummary>

________________________________

<Alex_> i assume the dial in isn't working for all

<Jan> Trying to connect by phone, but webex says the meeting number is invalid.

scribe Glenda

<KimDirks> *I'm having trouble too - it says the meeting isn't started.

<AWK> +AWK

<alastairc> Ah - the agenda was for thrusday, where is the link for tuesday?

<Ryladog> WebEx is for Thursday call

<interaccess> https://mit.webex.com/mit/j.php?MTID=m2c6416ba23424cf61cbea8b2300fcc9e


<Ryladog> Thanks!

<Joshue108> np

AGWG summer schedule https://www.w3.org/2002/09/wbs/35422/AWAG_summer_2017/results


open item 3

AWK: please respond to summer schedule questions so we can plan for our summer meeting schedule

<Lisa_> Not managing to join. Is the meeting now?

<Joshue108> https://mit.webex.com/mit/j.php?MTID=m2c6416ba23424cf61cbea8b2300fcc9e


davidmacdonald: question about TPAC meeting dates for AG. so we can make travel arrangements.

MCooper: we should see a schedule forming soon, since May 31 was the end or the survey for suggested topics

open item 1

AWK: discussing Stephen Repsher’s comment on color. AWK disagrees and says this was processed.

MCooper: Is this just editorial? Personally wonder if we should leave this color change out.

AWK: the intent of the working group is that this is editorial.

MCooper: I’m 85% convinced

AWK: Bruce has comments about typos. Also comment on color item #11 feels normative to him.
... Bruce’s last comment is changing fix we all agreed on.

<Alex_> +1 to Josh

Joshue108: is it worth it to make this change to 2.0, or just roll it into 2.1 (to prevent pushback and confusion related to 2.0).

Katie: I think we need to leave this for another time. Worried it will confuse people. Important that we end up doing it, but not if it confuses everyone.

Makoto: I should have expressed my question before consensus. So it has been very clear to me that 1.4.1 covers "Color" and 1.3.3 covers other than "Color". If we'll add "color" to 1.3.3, what would be the difference between revised 1.3.3 and 1.4.1

AWK: meaning of 1.3.3. and 1.4.1 is not changing. 1.3.3 is talking shape, size, visual orientation, including color. If you provide click on the red button. 1.4.1 use of color, is talking about not relying on color as the only means of conveying information, like if an error state is only conveyed in red.
... Judy’s concerns about proper messaging and understanding.

<Joshue108> +1 to Michael

<Zakim> Joshue, you wanted to say I don't want to burn cycles defending a relatively minor descision when we have bigger fish to fry with 2.1

Jason: change to 1.3.3 is just clarifying what was already there. not a normative change. interpretation is correct. But if people have concerns we could delay to 2.1. Rather do it for 2.0.

Joshue: I’m not against us doing this. Don’t want to burning cycles on something minor.

MichaelC: typos, we should fix them. A year ago, we said last call. And we have more. We need to draw a line. This is the errata we have collected up to date x.

<Zakim> MichaelC, you wanted to note every time we do an approval round people find more typos ;)

Katie: I think we should, I just don’t think we should do it now.

AWK: if we don’t do it now, I don’t think we ever will.

<JF> +1 to Katie

<alastairc> I don't feel strongly, I'd lean toward rolling into 2.1 if it can't be done quickly now.

MichaelC: lean toward wanting to do errata now. It will be less helpful after 2.1 is published.

<Joshue108> Access code: 642 418 206

Katie: people will continue to comply with WCAG 2.0 for 10 years

JF: agree with Katie. WCAG 2.1 does not invalidate WCAG 2.0. Regulator perspective, a lot of people will still use WCAG 2.0.

JasonWhite: problem with new errata, but we should at least clear the list of known errata.

<Zakim> MichaelC, you wanted to say we need a ¨trigger¨ for when to take it up again if we defer

MichaelC: we don’t have consensus. but we are having problems getting this through, why would we try again.

<Lisa_> I can not join the web ex

Joshue: +1 to what MichaelC is saying. So difficult to get errata published. If not now, then when. This is an opportunity to tidy up things that we know are wrong.

+1 to what Joshue just said. Publish errata.

<Lisa_> Jan is on the call she is the SC manager. Start without me

<Lisa_> Maybe I have the wrong meeting number

<Joshue108> https://www.w3.org/WAI/WCAG20/errata/


AWK: errata are published, this is a proposal to update the WCAG 2.0 edited version.

RESOLUTION: We do not have consensus to publish new WCAG 2.0 edited recommendation

Next item

<gowerm> @awk I also have what I would call errata about style inconsistencies in SCs

AWK: Survey shows consensus. “The first change is to move the Understanding document out of "TR" space. This will result in the Working Group being able to publish corrections to the Understanding document immediately with a CFC rather than publishing updates only every six months.”
... “The second change is to clarify with the Working Group that we will do a CFC to clarify that the Understanding documents are approved prior to major releases (CR, REC) but that additions and changes to the content of the Understanding document will be made in an iterative process as the group works on success criteria.

<Zakim> MichaelC, you wanted to address JS comments

MichaelC: publishing to TR constrains our publishing. And it has a new dataed version. Non TR means that search engines are more likely to find latest content.

davidmacdonald: understanding documents have a lot of authority, worried about frequent updates impacting that authority.

katie: i think the updates to the understanding documents need to be agreed upon.

AWK: for WCAG 2.1 we will not do a cfc for every while content is being built. But we will have cfc after these documents are more stable.

<bruce_bailey> I am for the move out of TR space, and I always send folks links to the undated (most recent) version -- but this has been extra

<Zakim> bruce_bailey, you wanted to say I like having the dated versions

JF: fully support moving these non-normative docs into a place where we can update them more frequently.

<Lisa_> Tried the new WebEx. Still can't join.

Bruce: I like having dated versions, but I think it will be easier going forward without all the different dated versions.

<Lisa_> Hell is copying meeting numbers to the phone

Jeanne: hope new procedure will keep a history of changes

AWK: yes, it will be in github and the decision log

<Lisa_> Giving up. Sorry folks.

MichaelC: we can do it in serveral ways: github commit history, and change logs, and dated snapshots at keypoints.

<Lisa_> Tried for 45 minets

<gowerm> Lisa, check your email

<gowerm> Remailed dial in number

AWK: I think it will be easier to look through a github commit list.

+1 to AWK’s comment!

DavidM - I will not object

RESOLUTION: Accepted as proposed “Approval process for Understanding documents”

next item

<Zakim> jeanne, you wanted to say that it is important to keep a history, and I hope this new procedure will do that.

next item

<JF> +1 to Jason

AWK: pretty good agreement. Comments from Jason echoed by James. Jason’s comment is about that speech tools should do more. Not willing to put burden on content providers.

Katie: for years we included things that screen readers could have done, until screen readers filled in the gaps.

JF: concerned and conflicted, not happy putting all of this requirement on the author. We can solve this with user agent and can accomplish this.

Joshue: addressing particular user needs

<Ryladog> +1 to David

davidmacdonald: not to0 hard to do, reasonable to ask the developer

<Joshue108> Kims video https://www.youtube.com/watch?v=xzSyIA4OWYE&feature=youtu.be


davidmacdonald: page is listening to the page for a keystroke, if you speak a word and it is typed for you, and it includes a letter for a key that has been hijacked, it will trigger that shortcut. JS developers say it is not unreasonable to have this SC

<Ryladog> Can we include the video along with the SC in the Draft to help commentators understand the issue better?

<Joshue108> We could

mikeg: author controlled situation, if the author created a single key shortcut, they should have responsibilty to make it easy to turn off that single key shortcut. not just a speech issue, this impacts and benefits users with mobility issues too.

alex: address accommodation deficiencies in AT, concerned that this creates risk for adoption (asking too much). Concede that disabling the single key shortcut is doable. 3rd point, are we writing an SC for only 1 speech to text AT. Seems onerous.

<Ryladog> But we are helping the build the expectation

JasonWhite: if WCAG 2.0 very careful in allowing in an SC that dealt with a screen reader gap. I’m open to the potential.

Joshue: reminder, we are publishing for public review. Is this a SC that spans more than 1 speech AT?

<JF> I think we also need to keep on top of what HTML 5.2 is doing with Accesskey (http://w3c.github.io/html/editing.html#assigned-access-key)

AWK: I was talking about people with hand tremors.

Joshue: I think we should include for public review.

<Joshue108> +1 to Mike Gower

<Ryladog> +1 to Mike

<jeanne> +1 to Mike

<Wayne> +1 to Mike

gowerm: really suprised about your comment, the Gmail situation is exactly what we are requiring with this SC. Author has to allow you a way to turn off a single shortcut key. This is not a single AT issue.

+1 Mike

<Jan> +1 to Katie's point to put it out there. This single-key keystroke issue can also affect people with cognitive disabilities

<AWK> https://rawgit.com/w3c/wcag21/single-key-shortcuts_ISSUE-69/guidelines/#character-key-shortcuts


Alex: add more than speech recognition as benefit.

<gowerm> I agree taht the understanding document is very biased to speech, and it shouldn't be

AWK: whole draft has understanding doc that includes benefits to keyboard only and speech users

Joshue: this SC is broader. it helps keyboard and speech. And be cautious about throwing something out just because it helps 1 thing. that 1 think may be a very important barrier to remove.

<AWK> Jan: Need to add cognitive disabilities use case to Understanding document to clarify that benefit

<Joshue108> +1 to Jan

Jan: this also effects people with coga and low vision. We need to add more benefits to all the different types of disabilities. (also echos what Joshue just said). If this is being created by the author, they need to be responsible for not creating a barrier.

<gowerm> +1 get it out there. I've volunteered to rewrite the understanding doc

<jeanne> +1 to Jan

+1 jan

JasonWhite: I think this is giving me impresion that this is a solution looking for a problem. Ask rational to be reviewed. Objection stands.

JF: stand down for now, let’s get it out there for wider review. that has value.

Alex: I don’t really object to it, except the benefit needs to be rewritten. I can’t accept it if it says it is only to benefit a deficienciy in one AT.

AWK: any objections other than JasonWhite

<alastairc> I've been waiting for the SC to settle before writing the understanding for mine.

<jeanne> +1 MikeG thanks

MikeG: I’ll address the issue in benefits (understanding) to address Alex’ suggestion

<Ryladog> Thanks to Mike for offering to update Understanding info fo this proposed SC

JF: minor reservation about non-character key. Can we clarify that it is a modifier key.

<jeanne> +1 JohnF, it's a modifier key, and that is what is most needed.

<davidmacdonald> character c\key single printable Unicode code point, any keyboard character that is printable, i.e. letters of the alphabet including capitals, punctuation, numbers, and symbols. Note that the Space and Enter keys, which return empty spaces rather than characters, are not character keys.

<Joshue108> +1 to seeing more examples of user groups etc where this SC would meet a real need.

<gowerm> Yep, I'll ensure that's captured Josh

<Joshue108> thanks Mike.

RESOLUTION: Accepted as proposed, with need for futher clarifications in understanding doc

AWK: not ignoring your objection, assume you will reply your object during the CFC process.

JasonWhite: yes

<Ryladog> :-)

next item

<Joshue108> https://rawgit.com/w3c/wcag21/change-of-content_ISSUE-2/guidelines/#change-of-content


<davidmacdonald> https://github.com/w3c/wcag21/issues/2


<AWK> https://rawgit.com/w3c/wcag21/orientation_ISSUE-70/guidelines/#orientation


david: we talked offline, i’m okay with it going out. I stand down.

AWK: jamesn said change in orientation has not been addressed. What did he mean?
... some applications are locked in one orientation. If you have your device locked to your wheelchair, you should not have to perm tilt your head to the side.

<davidmacdonald> The content is operable in the device orientation that is used to load the web page, except where orientation is essential for use of the content.

<JF> I'd tweeka "used to load the page" to "on initial page load"

MikeG: trying to understang rational. why suppress the ability to change orientation after page load?

AWK: this would not force anyone to lock orientation on page load, ideally users can view content in the orientation they have their device (do not recommend suppressing after page load).

<jeanne> +1 David's amendment

<JF> by all

RESOLUTION: leave this open

<laura> Bye

RSSAgent, make logs public

trackbox, end meeting

<JF> * trackbot, with a T ;)

trackbot, end meeting

Summary of Action Items
Summary of Resolutions

  1.  We do not have consensus to publish new WCAG 2.0 edited recommendation<https://www.w3.org/2017/06/06-ag-minutes.html#resolution01>
  2.  Accepted as proposed “Approval process for Understanding documents”<https://www.w3.org/2017/06/06-ag-minutes.html#resolution02>
  3.  Accepted as proposed, with need for futher clarifications in understanding doc<https://www.w3.org/2017/06/06-ag-minutes.html#resolution03>
  4.  leave this open<https://www.w3.org/2017/06/06-ag-minutes.html#resolution04>

[End of minutes]