W3C

- DRAFT -

Web Content Accessibility Guidelines Working Group Teleconference

12 Apr 2016

See also: IRC log

Attendees

Present
AWK, JF, Makoto, EricE, AlastairC, adam_solomon, Laura, David, KimD, Kathy, Mike_Elledge, marcjohlic, Katie_Haritos-Shea, JamesNurthen
Regrets
Patrick_Lauke, John_Kirkwood, Sarah_Horton, Sarah_Swierenga, MichaelC, Joshue
Chair
AWK
Scribe
David

Contents

<adam_solomon> cant find the password to webex

<adam_solomon> got it

<AWK> +AWK

Announcements

<scribe> Scribe:David

John: Didn't see anything on the agenda about WCAG next

Andrew: we can add to agenda after surveys

<JF> Kick-off email is here: https://lists.w3.org/Archives/Public/w3c-wai-ig/2016AprJun/0014.html

Survey: https://www.w3.org/2002/09/wbs/35422/5April2016_misc/Results

<AWK> https://www.w3.org/2002/09/wbs/35422/5April2016_misc/results

AWK: Issue 169 Redundant 13 people agree, 5 don't... James and micheal aren't here...

AWK SKIP FOR NOW

Issue 168

168

Issue 168

Do buttons have same status as links, 2.4.4

<JF> +1 to what Andrew just said

Alastair: Is it about link text in button layout or a form button

JF: Agree if it's an anchor or button... if it's a call to action, clicking on it is a get not a put, fetches, irrespective, asking end use to do something, so text should be descriptive... therefore 2.4.4

Mike: Button is different from link... submitting, cancelling etc... links and buttons have different purposes

Adam: we are talking about 4.1.2 and 2.4.4,

AWK: I interpret 2.4.4 as a special case for links

S/I interpret it as the button acting as a link./

AWK: I cannot find WCAG text that allows us to apply link requirements to buttons

JF: Using a button when it should be a link, no arguement but it is being done so we should address it

Adam: should you be able to use context around button describe the button, as we do with links

<yatil> [EricE leaves]

AWK: I believe it is something we should cover but don't think we do cover it...
... web page defn ex two. links or buttons... clearly a distinction between links or buttons...

<AWK> David: Agrees with AWK. feels that 4.1.2 applies to buttons but 2.4.4 doesn't

<AWK> ... part of the reason links are different is due to existing SR support for reading expanded link text

Alastair: should we say if button is acting as a link then 2.4.4 should apply

<jamesn> note I have an (old) action to clarify this - https://www.w3.org/WAI/GL/track/actions/139

<Zakim> jamesn, you wanted to say I have asked this before

<JF> Strong +1 to the idea that there is more "accountability" in 2.4.4

James: I have an old action 2011 to clarify this... it was clear not to apply to button, buttons need to make context in the label

Adam: sounds like you are saying it should logically it should but what does the SC say...

James: clearly not covered in 2.4.4, and 2.4.9 even more...

David: 2.4.4 was a leniency to allow ambiguous text in the actual link

JF: Today buttons are being used as links... so we need an errataetc...

AWK: Do the words cover "button", they don't, then we have to rely on the intent, which it seems there was no intent to apply it to buttons back then.

<Zakim> JF, you wanted to ask about <div onClick>

AWK: not convinced 2.4.4 is for buttons

what about a DIV, acting as a link

AWK. I'd look at the a11y API to determine whether the user agent treats it as a button or link

Adam: could it be argued, ypu need it's text to describe it's purpose, "read more" but link is where you are going...

<Ryladog> +1 to link and buttons that behave the same need the same requirement

<KimD> +1 buttons are not covered in 2.4.4. and we take up in the future

JF: Factual of what elements are vs. author intents...
... defer to WCAG next... ok with me

<adam_solomon> i take it back, i agree with awk: button is not a link

AWK: some distinction in WCAG between link and button, we can't remap the element based on author intent... messy

<laura> I'm not convinced 2.4.4 covers buttons. Prefer taking up in WCAG next.

Alastair: If a button is acting as a link, is the role incorrect under 4.1.2

David: I'm hoping in the near future we'll fail links that don't have context programmatically, using labelledbyby, etc...

s/Alestair/Alastair

<AWK> JF: reiterate what James said - we say that authors need to use the right element

back

<scribe> Scribe: David

<AWK> ... if WCAG 2.0 doesn't specifically address buttons in 2.4.4 then we need to add it to the list for WCAG .next

JF: Should punt it to WCAg Next
... strict reading on WCAG, Buttons not included in 2.4.4

AWK: We can propose respond 168 saying WCAG doesn't cover buttons in 2.4.4 This is seen as a gap to be address in WCAG.NEXT

<JF> Draft Resolution: The Working Group has concluded that WCAG 2.4.4 (Issue 168) has determined that <buttons> are out of scope per a strict read of WCAG 2.0. The Working Group recognizes this gap, and resolves to address that gap.

RESOLUTION: The Working Group has concluded that WCAG 2.4.4 (Issue 168) that <buttons> are out of scope per a strict read of WCAG 2.0. The Working Group recognizes this gap, and resolves to address that gap.

<AWK> Draft resolution: The Working Group has concluded that WCAG 2.0 SC 2.4.4 does not cover button elements per a strict read of WCAG 2.0. The Working Group recognizes this gap, and resolves to add this as an issue for consideration in a post-WCAG 2.0 version

<JF> +1 to taht

<Ryladog> +1 to remove it

<AWK> Draft resolution: The Working Group has concluded that WCAG 2.0 SC 2.4.4 does not cover button elements per a strict read of WCAG 2.0. The Working Group resolves to add this as an issue for consideration in a post-WCAG 2.0 version

Adam: some group memeber don't think this causes a "gap" but rather 2.4.4 opens for more leniency

s/The The Working Group has concluded that WCAG 2.0 SC 2.4.4 does not cover button elements per a strict read of WCAG 2.0. The Working Group resolves to add this as an issue for consideration in a post-WCAG 2.0 versionWorking Group has concluded that WCAG 2.4.4 (Issue 168) that <buttons> are out of scope per a strict read of WCAG 2.0. The Working Group recognizes this gap, and resolves to...

scribe: address that gap./

RESOLUTION: The Working Group has concluded that WCAG 2.0 SC 2.4.4 does not cover button elements per a strict read of WCAG 2.0. The Working Group resolves to add this as an issue for consideration in a post-WCAG 2.0 version

Issue 157

AWK: LVTF says hover state should have contrast, active state ok if not sufficient contrast

Adam: I can live with that... I brought up another issue... about tabbing away.

James: might be out of window at large magnification
... Sarah says active state should apply...

<AWK> David: There's a great reason not to in that there is value in having a substantial change inn contrast to indicate that the button has been pressed

<AWK> Proposed change to first sentence:

James: I agree...

David: We should distinguish for people that active state is a momentary pressing action

<AWK> WCAG interprets SC 1.4.3 to require that the text of links and controls which changes in response to focus and hover events meets the appropriate contrast requirement.

<AWK> Both hover and focus states impact low-vision users, but the active state is not explicitly required to meet the contrast requirement:

<laura> Should “WCAG interprets” be “WCAG WG interprets” ?

David: add a sentence about active state

<AWK> Both hover and focus states impact low-vision users, but the active state (the split-second state when a button or control is being clicked or pressed) is not explicitly required to meet the contrast requirement:

<AWK> Both hover and focus states impact low-vision users, but the active state (the typically split-second state when a button or control is being clicked or pressed) is not explicitly required to meet the contrast requirement:

Adam: sometimes someone might hang on the active state, while trying to decide.

AWK: the esc key should let you stop the action of a helod down active state

<Makoto> https://lists.w3.org/Archives/Public/public-comments-wcag20/2014Feb/0039.html

Makoto: would like explanation for the different response. I've been allowing this to Japanese people, I need to explain why. but can live with change.

need rational

<AWK> Add: This is a change from previous advice offered by the working group as a result of input from the Low Vision Task Force which identified additional concerns.

<KimD> +1 to AWK's add

Makoto: SC has not changed, interpretation has changed, we need to explain, in understanding document for example. Want to have documented explanation

<AWK> Add: This is a change from the previous interpretation offered by the working group as a result of input from the Low Vision Task Force which identified additional concerns that the working group had not considered, and which are addressed below.

David: I can update understanding.

<JF> +1 to that

+1

Makoto: Sounds good to me

<Ryladog_> +1

RESOLUTION: accept response as amended.

<AWK> Trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. The Working Group has concluded that WCAG 2.4.4 (Issue 168) that <buttons> are out of scope per a strict read of WCAG 2.0. The Working Group recognizes this gap, and resolves to address that gap.
  2. The Working Group has concluded that WCAG 2.0 SC 2.4.4 does not cover button elements per a strict read of WCAG 2.0. The Working Group resolves to add this as an issue for consideration in a post-WCAG 2.0 version
  3. accept response as amended.
[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/04/12 16:32:32 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/present +David//
Succeeded: s/Present +KimD//
Succeeded: s/CAG/WCAG/
Succeeded: s/TOPIC: 168/TOPIC: Issue 168/
Succeeded: s/TOPIC: 168/TOPIC: Issue 168/g
Succeeded: s/dkfferent/different/
Succeeded: s/AWK: I interpret it as the button acting as a link.../AWK: I interpret 2.4.4 as a special case for links/
Succeeded: s/shpuld/should/
Succeeded: s/+!/+1/
Succeeded: s/a11y API/a11y API to determine whether the user agent treats it as a button or link/
Succeeded: s/Alestair/Alastair/
FAILED: s/Alestair/Alastair/
Succeeded: s/resoluiton/resolution/
WARNING: Bad s/// command: s/The The Working Group has concluded that WCAG 2.0 SC 2.4.4 does not cover button elements per a strict read of WCAG 2.0. The Working Group resolves to add this as an issue for consideration in a post-WCAG 2.0 versionWorking Group has concluded that WCAG 2.4.4 (Issue 168) that <buttons> are out of scope per a strict read of WCAG 2.0. The Working Group recognizes this gap, and resolves to...
Succeeded: s/157/167/
Succeeded: s/167/157/
Succeeded: s/oressing/pressing/
Found Scribe: David
Inferring ScribeNick: David
Found Scribe: David
Inferring ScribeNick: David
Default Present: AWK, JF, Makoto, EricE, AlastairC, adam_solomon, Laura, David, KimD, Kathy, Mike_Elledge, marcjohlic, Katie_Haritos-Shea, JamesNurthen
Present: AWK JF Makoto EricE AlastairC adam_solomon Laura David KimD Kathy Mike_Elledge marcjohlic Katie_Haritos-Shea JamesNurthen
Regrets: Patrick_Lauke John_Kirkwood Sarah_Horton Sarah_Swierenga MichaelC Joshue
Found Date: 12 Apr 2016
Guessing minutes URL: http://www.w3.org/2016/04/12-wai-wcag-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
[End of scribe.perl diagnostic output]