Meeting minutes
<Chuck_> test
<Ben_Tillyer> Should be on the exemption list
alastairc: Waiting for Charles, get report from test requirements while waiting
Test requirements subgroup report
Juanita: test requirements as methods subgroup
… write methods from other subbroups
Juanita: split into sub subgroups and came up with examples
wendyreid: Prescriptive requirements [reviews slides]
… results pass or fail
… image with non-empty accessible name and flashing
… broke into test sets, focus on binary pass/fail procedure
… trying to apply to different technologies, think about how to break down to apply to techs and use cases
… [reads procedures]
… first pass, very pass/fail scenario, should apply to different scenarios
Poornima: Adaptive requirements [reads procedures]
… examples, contrast, how user wants to adjust based on needs
… different input modes
… understandable color contrast [reads slides]
… computational and quantitative methods
… how to define, need research to define
<alastairc> Any questions, please get on q, we can ask between presenters or at the end.
Poornima: input modality requirement [reads slide]
… adaptations for input modality, keyboard, switch device
… qualitative tests, computational tests [reads slides]
Rachael: extensible requirements, multiple ways to measure [reviews slides]
… color contrast requirements example
… reading level examples
… extensible requirements supports new methods, e.g., AI-based testing
Jason_Khurdan: protocol requirements
<Chuck_> There's a LOT of excellent work here!
<Ryladogg> Agreed
Jason_Khurdan: example abbreviations [reads slide]
<GreggVan> Can someone repost the link to the powerpoint? my IRC was dicconnected
Juanita: Issues for discussion
… [reads slide]
… structure of guidelines, where to go from here
GreggVan: Adaptive, relate to different needs, e.g., contrast, how to turn into requirement? Need high, low, whatever someone needs
… what is the requirement if it changes for different peopl
Poornima: Baseline idea, bring out methods to define contrast ratio for context of elements
… adaptive requirements related to context, bring out what works for variations, research needed to bring out equations that satisfies most adaptations
GreggVan: Sounds like when create, need to keep broad range of needs in mind
… requirements that change with users, example of wording of requirement that's adaptive
… sounds like, need to develop web page that meets user needs for color contrast, does that mean need a control? That would be requirement
<Zakim> mbgower, you wanted to say great work and I have comments to strengthen
<Chuck_> +1 to mbgower, helps me too!
mbgower: Really useful, feedback on all, what's best way to provide?
… specific, wants really good examples, make sure relevant to discussion, writing, share deck?
jeanne: Great to have example, grateful for all work to have example, a lot more clear, can build out better
… concerned about adaptive, different direction from prior group
… may need to adjust back or work through comparing examples
… also protocols, seems like different direction, 3rd proposal
… discuss what proposal to follow, how they work together
… groups have worked on what's in a method, would want that to come forward
alastairc: Join meeting and brief on previous work?
Wilco: Really likes, appreciates, not sure about next steps but WG chairs need to decide how to get feedback
… hoping every group would have PRs but not panning out
<jaunita_george> We plan to have a pull request, but that's a couple of weeks out.
Wilco: requirement term, intended as placeholder until decided whether methods or outcomes
… explore whether should be methods
<Rachael> +1 to these being methods
<Zakim> alastairc, you wanted to ask if we should collapse to 2 types.
Wilco: ideas fit as methods, maybe should start calling types of methods
alastairc: chair hat off, might not need all different types, adaptive might be way of coming up with requirements that become prescriptive
… overlaps, might all collapse down to two
Rachael: hat on, email AG group with feedback, subgroup take into account, could do survey
… hat off, question about context, user context or different context
… yes, user context, another way to do with if/then, prefers "conditional"
… merge adaptive and extensible that's conditional but not user centered
GreggVan: +1 to several people, thank you for doing critical work
… also definition of terms clarity, have 2–3 example SCs for each
… some come down to conditional
<Chuck_> ... and "guidelines"
<Zakim> bruce_bailey, you wanted to ask how many more meetings subgroup has scheduled ?
GreggVan: contrast example, 2 ways of measuring with different result, which do I design to? Both? Every? Must be answer to whether passed
bruce_bailey: Tough and valuable, thank you
… how many more meetings for group?
Juanita: At least 2, asked for 2-week extension, take into account holiday season
alastairc: Look through, email group with feedback, subgroup take into account
<alastairc> https://
alastairc: Checkin about culture, trying to keep checkins on regular cadence, Charles isn't here
<Chuck_> Chaals' email is in the survey
alastairc: will reopen survey, can email Charles, interested in feedback, working through feedback for better ways of working
… come back when Charles is available
<GreggVan> thx
<Zakim> GreggVan, you wanted to ask if there is an address to email the group directly or if all comments should go to the full group
WCAG 2 https://www.w3.org/2002/09/wbs/35422/wcag22-misc-normative/
<alastairc> https://
Question 1 - Difficulties with inconsistency of Target Size (Minimum) #2695
Chuck_: [reads survey question]
… [reviews responses]
mbgower: [reviews response]
… increases possibility of increase in density of controls
Chuck_: [reads responses]
bruce_bailey: Troubled by the defect mgower's describes
Chuck_: [reads responses]
GreggVan: Proposal for "x" pixels and thought would be 24, target size next to each other as long as large enough, also allows small buttons spaced
<Zakim> bruce_bailey, you wanted to change vote from survey -- because of problem MG just describe
<Zakim> alastairc, you wanted to talk to size chosen
<JStrickland> should sizing be relative with minimums specified?
alastairc: picked 12, minimum of 24 divided by 2 = 12
<Zakim> mbgower, you wanted to say I have a bit more info on possible numbers to plug in, and a possible suggestion
alastairc: concern is how interacts with size and spacing
<kirkwood> If I could still vote per the previous survey timing, I would vote “Switch to the suggestion above in PR 2825”
mbgower: start increasing size from 12, further spacing between smaller targets, creates targets approaching 24, increase space around them
… calculation bumps it up
… points between centers of targets
… also none address diagonal targets
Wilco: Current approach better than PR, had approach in earlier version
… encourages small components and maximize space between as proposed in PR, harmful
… figure out how to do with measure horizonal and vertical
… very unintuitive as written
GreggVan: Earlier one has problems, proposed one doesn't
… need 24 pixel area for finger, 12px distance between point in this thing and others, have 24px circle
… not from corners, point in link to every other thing
… always have 24pt circle around thing
… trying to create clear space, doesn't increase density, always the same thing, always 24px
… don't want small controls, HCI issue
<Zakim> bruce_bailey, you wanted to say we are close
bruce_bailey: So close, important SC, agree closer previously
… if 24px, does that address density?
al
<alastairc> https://
<Wilco> No, the SC becomes even stranger with 24 px
Alistair to Wilco: I think we tried earlier draft that was close. What needed change?
Alastair: Would like to get to a decision or path to decision.
MikeGower: Proposal today versus existing one, consider nightmare 1 px target and 24 css spacing
… with current proposal, that drops down to 12 -- targets can be much too dense
… result is probably we will see much smaller widely spaced targets with this proposal.
Gundala: Consider example of letters being different targets , this language encourages those being densely packed together
GreggV: Issue thread gives lots of example with counter intuitive and inaccessible results
… tenstion between UI which works for finger and mouse...
<mbgower> Establishing a minimum size for a button would be useful; do we have research that can back up what we set?
GreggV: single pixel targets should always fail... there should be a minimum size PLUS the min distance
GreggV: I think solution is to have minimum size
<Chuck_> bruce: I would like to hear what happens if it's a naive 24 pixel space from target and any other edge of any other target.
<mbgower> it would double the space between targets
Alastair: If you pick one point from 24 css pixel from every other target, so then that doubles the size.
Alastair: I think we are closer with Wilco's previous suggestion.
<mbgower> I think practically a 24 pixel 'square' is an easy way to test for correct; it just doesn't work for our language
GreggV: at 12 px finger can easily hit two targets.
… previous versions were complex and led to some unexpected results...
… cannot have only target size and not spacing
<Zakim> Chuck_, you wanted to ask if we are trying to work and modify Wilco's proposal?
<Zakim> alastairc, you wanted to say where the spacing came from
Chuck: Is path forward to put more effort to Wilco's approach?
Alastar: The reason for the spacing exception is that orginaly we had 44 px minimum target size and that was too much...
… we consequently dropped down to 24 px minimum size as nominal requirement...
… but one can also have smaller button so long as there is enough spacing between targets.
[alastair screen sharing illustration]
Alastair: for button in row, designers can have medium sized buttons spaced out in the row...
<Zakim> GreggVan, you wanted to say that you made an excellent point about on screen vs real buttons. With real buttons you need to allow for fat fingers -- to not press the button next to it. With touch screens all touches are reduced to a point
Alastair: using only spacing the temptation is jus to make buttons smaller to pass the SC.
Chuck: How much time do want today Alastair?
<alastairc> Running out of points, suggest stopping now. IDeally someone (Wilco, mbgower ?) might check the issue with the previous suggestion
GreggV: With touchscreen, targets are essentially all reduced to single px target...
… touchscreens look at all px touched -- the touchscreen find middle of your touch and decides the single exact point...
<Zakim> GN, you wanted to remind on coordination issues and tremor
GreggV: I really think we only need to set minimum size because that is the way touch screen work. Spacing is a red herring
<Zakim> GreggVan, you wanted to say that those Gns comments are all good -- but they have to do with target size not spacing. so they speak infavor of size
Gundala: I don't think just target size and not spacing does not address people who have tremors or use alternative pointing devices.
GreggV: I agree with barrier -- but it can be solved with spacing and not spacing.
<Zakim> Chuck_, you wanted to end conversation and move on to question 2.
Alastair: Have we just dropped the spacing exception then?
<mbgower> That seems pretty rash at this point in the game
Chuck: As reminder, core requirement is 24 x 24 square.
Alastair: Spacing is there because we started with 44 pixel...
… as we dropped that number down, we added spacing exception to improve size.
GreggV: I think something like 16 px min size and requirement for 24 px spacing could work
<alastairc> move on
GreggV: it is easy to understand and can eliminate exception
Question 2 - Better clarity on inline targets for Target Size #2767
Chuck: we will leave this unresolved , keep on survey
[chuck reads survey Q]
<GreggVan> s / 16 px min size and requirement for 24 px spacing / "minimum of 16 px and the button plus spacing must be 24 x 24"
In Issue 2767 we discussioned the inline exception of target size. The preferred option from a WCAG 2.x meeting was: Inline: The target is a text link dependent on the line-height of non-link text. This narrows the exception to text links, and is clearer about whether something is in scope or not. It is implemented as PR 2824. Please see the working document of suggestions and examples, which shows what would be included / not-include[CUT]
Chuck: of those who agreed and commented...
Chuck reads Bruce comment: Similar exception for AAA Success Criterion 2.5.5 Target Size should also be updated or renamed (assuming this gets consensus).
Chuck reads Wilco comment...
[chuck moving on to agreement-with-adjustment comments]
[chuck reads GreggV comment]
GreggV: needs works, I did not suggest text
Chuck invites Wilco to expand on his survey comment.
Wilco: definition is missing some situations which should be covered
[chuck read Gundal's comment]
[chuck reads other comments]
[chuck invites other comments before open Q]
<Zakim> alastairc, you wanted to summarise examples
GreggV: can we just use text height ?
Alastair: i want to +1 mike comment in survey, that it is better and good enough , helps with consistent and easily provided rule ...
… should help with inter rater reliability
Alastair: Wikipedia provided rich test cases -- lots of text in various kinds of list, sometimes single words
<GreggVan> [09:28:21] GreggVan: q+ to say Exception "it is a text link/target and is at least xx point text"
MikeGower: This exception was primariliy target to link text and list of links...
<Zakim> GreggVan, you wanted to say Exception "it is a text link and is at least xx point text" and to say Exception "it is a text link/target and is at least xx point text"
MikeGower: when button is in line with line of text it can be a little sketchy
<Zakim> Chuck_, you wanted to mention Gregg's suggestion, does that refer to AWK's "line-height of text"?
<mbgower> we have never prescribed text size in WCAG
GreggV: I would like that we not exempt when text gets too small. For example 4 point is just too small and should not be afforded the flexibility we imply here.
AWK: We have never prescribed text height / size in wcag
<AWK> I had the same comment as Mike Gower
<AWK> All text, even links need to meet the resize requirements
Alastair: I don't think miminum text size is feasible, which is why we propose using lineheight of text , we might use "target size"
GreggV: I concure, someone can always expand text size. But would that not also apply to text in a pull down which might still just be text -- but needs a minimum target size.
<Zakim> alastairc, you wanted to comment on "determined by"
Alastair: I do not think drop down gets the exception because it might be effect by browser zoom, menu spacing not determined by text line height.
<alastairc> The target size is determined by the line-height of non-link text.
Alastair: There were some questions in survey around phrasing "determined by line height". Wilco?
<kirkwood> Curious, wouldn’t Zoom by a user agent exception for all of these topics today?
<alastairc> The target size is contrained by the line-height of non-link text.
<GreggVan> +1 to "constrained by line height"
<Chuck_> +1
Wilco: The height is "constrained by line height"? I really do not think "determined by" is technically correct
<alastairc> kirkwood - it is defined in CSS pixels, so not affected.
<kirkwood> +1
<Wilco> +1 to constrained, -1 to non-link text
<ShawnT> +1
<GN015> -1
<mbgower> I think we all understand the concept; we just need language to convey
<laura> +1
<Makoto> +1
<AWK> Same as gregg I think? line-height but not mentioning non-linked
<mbgower> +1 to constrained
[chuck echo's MG irc comment]
<mbgower> I'm fine taking out non-link text
<alastairc> Wilco - so what we it be constrained by?
Wilco: As per my comment, somethings are text but not list of text. Phrasing needs more deliberation.
<mbgower> trying to unmute :)
Gundala: Agree with Wilco, language does not seem quite finished
<mbgower> yeah, this is what I was going to say. We need soemthing other than the 'link' to constrain the link's height.
<mbgower> Otherwise they all pass!
Alastair: Point of current phrasing that one needs something -- that is not hypertext -- to compare the link target size against.
<mbgower> I guess not :)
Alastair: We are trying to draw the line, something better than "text in a sentence" which is not good enough.
Chuck: As MG notes, we can't say link text height -- because then linked text *always* pass
<mbgower> 'typical type' is a couple of pixels under 24px. it doesn't take much
<Wilco> Suggestion: Inline: The target is part of a <a>text<a>, and the size is constrained by the line height.
<Zakim> Chuck_, you wanted to read out mbgower's comment
Alastair: please see examples from Doc -- what get the exception and what does not
<alastairc> Google doc: https://
<mbgower> That still doesn't capture links that are left nav, for example
Chuck: Wilco you note that hypertext links go back to the beginning of inter net
<GreggVan> when saying typical text is 24 pixels almost --- what point size is assumed?
<mbgower> They meet the defnitino of text
Chuck: MG asks about left nav bars?
<Wilco> It's not, default font-size in browsers is 16px
<mbgower> 16 pt with 1.5 height
<mbgower> 12pt with 1.5= 18; 14 pt with 1.5 is 21
[greg ask about nominal browser default. alastair answer 16 css px]
<Chuck_> The target is part of a marked up anchor (i.e. <a>text<a>), and the size is constrained by the line height.
Alastair: some comments about what would not ever be in scope? Wilco notes inline exception seems very broad.
<mbgower> I'm not sure how descenders fit into the calculation for font size (ie. if the bottom of a lower case g going protruding into the 1.5 space?)
<alastairc> Inline: The size of the target is constrained by the line height of non-target text.
Chuck: from survey, anchor text is this element A?
<mbgower> Yep, that works
WIlco: Survey comment is just about text. Nothing about anchor element.
<Chuck_> The size of the target is constrained by the line height of non-target text.
<Chuck_> +1
<mbgower> it is L2R language specific though
Alastair: this is similar, but maybe less technology specific
<Zakim> Chuck_, you wanted to echo mbgower's comment
JohnKirkwood: I am not sure this is doing what we want. Could be small text using larger line spacing. Only the letters, not spacing above letters, is target.
<GreggVan> inter line spacing -- instead of line height
Alastair: I think we are okay with small text with larger line height -- because of the other exceptions -- there would still be good spacing between lines of text.
<mbgower> yep, so long as we address specifically
<Chuck_> The size of the target is constrained by the line height of non-target text.
<mbgower> +1
Alastar: [responding to question about L2R languages] yes, we have been keeping in mind phrasing is not limited to left to right languages.
<Detlev> +1
<Ryladogg> +1
<Makoto> +1
<alastairc> +1
<Wilco> -1 I think this exception should only apply to targets that are part of text
<GreggVan> 0 which text ? where on page? adjacent ?
<ShawnT> +1
<GN015> -0.5 I still feel it can be miused, that is applied in unintended way
Wilco: This should only apply to text near non-text targets. Consider a bread crumb: might be line of text and one single character at end...
… breadcrumbs should not warrent exception
Gundala: Still have my previous concerns.
<Zakim> Chuck_, you wanted to read out mbgower's comment
<Wilco> https://
Alastair: I am struggling with describing why hypertext is constrained by text is a reasonable lens for the exception.
… we want to support reflow and client zoom, going through the examples the key seemed to be if the target was text -- but that is circular
<Zakim> GreggVan, you wanted to say -- if we require all pages to allow text enlargement without loss of function -- why are we so concerned about this since a size bump of the page would make text larger. MAYBE it should be "except if it is a text link"
<Zakim> Chuck_, you wanted to ask GN and Wilco a question?
Alastair: so having target size constrained by line height is the sweat spot
<mbgower> been down that road, Gregg. Folks didn't like resize text (or zoom) as a solution for target size
GreggV: Can we just say text that is link?
Gundala: Can you demonstrate that using lineheight does not lead to exploits?
Wilco: My concern is that this decision feels too rushed.
<Zakim> mbgower, you wanted to say the current wording will create HUGE inter-rater reliability
Alastair: Wilco, and other, please look at examples. The five of us really beat the present wording around and came to good inter-rater reliablity.
MG: It is impossible to get people to agree as to "What is a sentence"? Using this odd phrasing is objective.
Chuck: no resolution