See also: IRC log
<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
RESOLUTION: go for CFC
1+
<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?
<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)
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]