Accessibility Guidelines Working Group Teleconference

18 May 2017

See also: IRC log


Detlev, MichaelC, alastairc, steverep, ChrisLoiselle, Kathy, Greg_Lowney, MikeGower, Laura
Deltev, Detlev


<Detlev> I can scribe

<Detlev> scribe: Deltev

<Detlev> scribe: Detlev


AWK: worked through issues with straightforward solution

<alastairc> happy to +1, seemed straightforward

1.3.1 and 1.4.1 clarification on color seems gernerally accepted

<JF> +1 from

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

<AWK> in WCAG 2.0 https://github.com/w3c/wcag/issues/267

Will likely be implemented sent out as CfC

<ChrisLoiselle> yes



Resize Content: https://www.w3.org/2002/09/wbs/35422/ResizeContent-issue77/results

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

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_status#Issue_77_-_Resize_content

AWK: new section on open issues and surveys on github page

eight items fro comments and call minutes in there now

Alastair: has tacked issues that were most difficult

First relatino to resize text SC

Alastair: suggestion was to rais 1.4.4 to level A and have the new one on AA

AWK: thinks should be split and discussed separately, having two SCs
... then later talk about integration steps

Alex: If they are goig to be combined what will it look like?
... will it apply to text or other content too? Because that seems to fall into the exception for spatial layout

Alastair: not just text - with RWD browser zoom zooms everything

Alex: But nearly everything would be excemted
... will anything but text fall into the exemption (e.g. the ribbon of a web app)
... graphics, video, table - all exempt?

<Greg> Why would a ribbon be exempt?

Alex: anything else?

Alastair: ribbon shouldn't be exempt - only if it needs a particular layout

Alex: conventio nis horizontal for controls, vertical for content
... so what do you do with a ribbon in constrained width? Remove functionalities?
... at 400% ribbon would crowd out content

<Zakim> steverep, you wanted to say that fixed layout elements still need to "minimize" scrolling

<Greg> Ribbons may be horizontal yet can wrap or use progressive disclosure, and can scroll out of view when its height is great compared with the display.

<Zakim> AWK, you wanted to say that the exemption is not for the full SC, just the scrolling/reflow aspect

Steve: even when content canot be fully flown the requirement should be to minimise scrolling wherever possible (?)

<alastairc> I took as a to-do item to define "fixed spacial layout" on tuesday, just haven't had a chance

AWK: understanding that the exemption for content zooming i.e. content should get bigger, just an exemption for reflow

<steverep> I had the exact opposite interpretation as AWK - I think it needs clarity obviously

AWK: hor scrolling would be OK for a table but not text
... explains how ribbon type controls should collaps into a menu button (but stil be available)

<Greg> I've noted before that the document suffers from ambiguous, dangling clauses that should be restructured.

Kathy asks for target size tzo be on tues agenda

<Zakim> alastairc, you wanted to say that image are better constrained to viewport width.

Alastair: RWD sites often resizes images to viewport width
... distinction between individual items and grouped items (like data tables)
... unordered list not a 2D item

<Greg> Labels

Alastair: other example would be Canvas games

AWK: cannot pin down exact object types but talk about it generally (where reflow would lose meaning)

<AWK> Current: Content can be resized to 400% without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content where fixed spatial layout is necessary to use or meaning.

AWK: need to address definition of fixed spatial layout

Alex: Did 400% on word - ribbon fills entire screen - would that fail?
... Ribbon already quite big

Bu this falls into " necessary to use "?

<Greg> Alex, ribbons may be horizontal yet can wrap or use progressive disclosure, and can scroll out of view when its height is great compared with the display.

AWK: another question was about the role of the UA (mobile UA do not resize the same way)

<Zakim> alastairc, you wanted to say that it isn't a content requirment

AWK: link to target size, where an exception exists for UA

Alastair: exception was taken out because it is not an author-controlled issue - it's all down to the UA

AWK: Does it make sense if things are not meant to be used on mobile?

<Zakim> Greg, you wanted to review survey comments

Alastair: yes because zooming 400% dioes effectively display at 320 CSS pixels

Greg: Ribbon might adapt dynamically (?)

Alastair: question oabout UA - definition

Greg: concept of host UA and inside a more particular UA e.g. for email
... UA inside UA not under author's control

certain content features like non-breaking white space could trigger horizontal scrolling - how do we handle that?

Alastair: seems to come under translation aspects of ATAG
... interested in examples causing problems

Greg: certain content wll eithe rcause truncating or hor scrollbars - will that cause Gmail to fail the new SC?

AWK: the author of Gmail would either have to honour email author'as intent, or cnformance to new SC.

<gowerm> It's not 3rd party. it's authoring tool

GregL: it is not an authoring tool but would have to decide whether it strips out bits

<alastairc> It does seem like a general issue that affects many SCs, not just this one!

Gregg: authoring tool would have responsibibility to conform

<alastairc> e.g. target size...

GregL: user use another tool that does not respect formatting in line with new SC

Gregg: then it should fall under the exception

mike: UA responsibility is to wrap stuff

(sorry I did not get all of this (phew

RESOLUTION: Leave open

<Greg> Those are all Greg not Gregg

<gowerm> Detlev: I've talked too fast my whole life. sorry

sorry for the Greg Gregg

where is the item?

Target Size: https://www.w3.org/2002/09/wbs/35422/SCreview_May_17/#wbsq4

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

<AWK> Current version: https://rawgit.com/w3c/wcag21/target-size_ISSUE-60/guidelines/sc/21/target-size.html

<AWK> Status: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_status#Issue_60_-_Target_Size

<gowerm> covered by "cannot be modified"

JF: the way this is written now, a native unstyled control will fail the SC
... wil get huge pushback

<gowerm> JT: that's covered by last exception

JT: same for selects

JF: SC as phrased now can't fly

AWK: falls under exception target

Mike: dropdown size of the native control can't been modified (so not under author's control)

JF: native link: meeting SC will call for CSS to meet SC

Mike: interesting point - the go link should fail

JF: could be any short link - demand for 44 px square not realistic

<JF> easy isn't the concern, backward compatibility is the issue

Alastair: It's easy to add padding to buttons and things - rare to see ustyled buttons on commercial sites - with select, the whole select is the target

<gowerm> so now a pure html form with no mods can fail? That IS a little nutty.

JF: 20 years old web content would automatically fail the new version

Why do they have to meet 2.1 - let them meet 2.0!

JF: SC will depend on additional technologies

<gowerm> dropdown box target is the whole select area, FYI

Alastair: That logic would rule out all new SCs

JF: select will never be 44 px high
... one proposal was to take total surface area instead of 44x44

<gowerm> yes/no radio buttons may fail

JF: How would this work in PDF?

AWK: It can work when you can make controls bigger

Alastair: CSS is part of the stack of a11y-supported technologies - if it is not you couldn't meet 2.1

Mike: checkbox with yes or no lables would fail the SC

<JF> correct

Mike: seems a bit nutty that you would have to add padding to yes / now checkboxes

JF: doesn't scale

<alastairc> it scales fine for new content, find an 'enterprise' that doesn't style things!

<AWK> Detlev: question question - why is it necessary for legacy content to meet WCAG 2.1 right away? Why shouldn't they have to do something to meet the new standard.

JF: UK references the most recent spec, that's why this is significant

<alastairc> The UK law doens't reference any particular guidellines.

JF: People will not accept requirement to restyle legacy content
... Even taking out inline text links, the SC would mandate buttons and form controls to be min 44x44!

DmD: SC were initially developed with mobile UA in mind - not initially thought to be applicable to desktop
... distinction could not be maintained (due to hybrid devices etc)

<Greg> John, target size is as useful on desktop as on mobile.

DmD: put it out with exceptions and see comments

AWK: if this was restricted to small form factor devices would we have the same issues with unstyled controls?

DmD: too rigid in not being able to define mobie devices

JF: Doesn't zooming meet the target size requirement?

<alastairc> Overall, I cautiously think it would be feasible, but given the cycles burned on this, I go back to suggesting that we put it in with no-exceptions at AAA.

<marcjohlic> +1 wish there was a way to say this is applicable only to mobile / small factor only. Not sure how to get there though.

<AWK> Detlev: Wonder what would happen if we did exclude unstyled native controls?

JF: feels we are asking too much

maybe adding native controls as excepton would still have benefits for site that DO style controls

<Alex> depends on how many features (buttons) is needed

<Zakim> steverep, you wanted to propose a possible alternative to maximize targets to their containers

AWK: will be picked up again in next call

<JF> every tabel cell then would need to be 44 X 44?

RESOLUTION: Leave open

Steve: techniqhes to maximise control sizes (like make whole table cell clickable)

Summary of Action Items

Summary of Resolutions

  1. go for CFC
  2. Leave open
  3. Leave open
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/05/18 16:35:08 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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/a+//
Succeeded: s/male sens/make sense/
Succeeded: s/Gre,/Greg/g
Succeeded: s/unsettled native/unstyled native/
Present: Detlev MichaelC alastairc steverep ChrisLoiselle Kathy Greg_Lowney MikeGower Laura
Found Scribe: Deltev
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Scribes: Deltev, Detlev
Found Date: 18 May 2017
Guessing minutes URL: http://www.w3.org/2017/05/18-ag-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]