<jallan> scribe: jallan

Survey: https://www.w3.org/2002/09/wbs/35422/resolvingissues3/results

issue 296 & 315 glossary items

<laura> https://www.w3.org/2002/09/wbs/35422/resolvingissues3/results#xq6

awk: spend about 5 min on this topic... as non-normative.
... don't want to change meaning of SC as result of glossary

<Alex> is it just me or is Andrew's audio choppy?

<Detlev> It's just you... I think

awk: don't think calling our font-icons as they can be made accessible.

<Alex> thanks! i'll dial back in

awk: MikeE ask do we have initialism in def.
... yes
... MCooper = be very careful about changing defs.
... any thoughts

sr: notes within glossary have not been transferred

<Zakim> steverep, you wanted to say that notes within glossary items seem not to have transferred to 2.1

awk: they will be

<Zakim> gowerm, you wanted to say can someone provide an example of a page that needs this exception?

<Brooks> For reference, here's an icon font - https://aftertheflood.co/projects/atf-spark/

awk: any objections to including initialisms and acronyms?

<laura> Add icon fonts to the definition of non-text content: https://github.com/w3c/wcag21/issues/296

detlev: happy to leave def as is and move on

awk: happy to not modify definitions. any objections?

RESOLUTION: not modifying definitions

Survey: https://www.w3.org/2002/09/wbs/35422/resolving_issues_2/results (Questions not marked “completed CFC”)

Issue 620

awk: fairly good agreement
... may have talked about this last week. thought someone was doing more work
... was on me
... will do that after this call

RESOLUTION: leave open

<steverep> I can work with AWK on it after the call

jason: on list to help with revision

detlev: will try to draft something

issue 622

awk: guideline text
... suggestions have been submitted
... don't require user ability, provide alternatives

<AWK> "Provide alternatives for user input via device sensors."

<AWK> "Do not use device sensors in ways that require physical capabilities of the user"

sr: use sensors as option should not be said.

detlev: if you use sensor input provide an alternative. was the intent. not worded well.

sr: doesn't work for orientation.

awk: depends on reading.

"Do not use device sensors in ways that require physical capabilities of the user"

<Greg> So "do not use" should be "do not rely on" or "do not require".

detlev: would outlaw shaking and other methods of input. they need to provide alternative input.
... +1 do not rely on

"Do not rely on device sensors in ways that require physical capabilities of the user"

<jasonjgw> "Ensure that users with a variety of physical capabilities can use content that relies on detection of motion or device orientation."

awk: a bit difficult to parse
... "do not rely on device sensor input"

detlev: jason formulation is problematic/paradoxical. prefer latest short form ^^^
... "do not rely on device sensor input"

<Greg> Technically, mice, keyboards, and touchscreens rely on device sensors in the broader sense.

awk: "do not rely on device sensors for user input"

<Greg> Thus I think we should be more specific than just "device sensor input".

jason: have guideline text broader than SC test

<Detlev> +1 for that latest version

detlev: guideline cannot enumerate all of the specifics. That should be left to SC
... short guideline is fine.

awk: keyboard used for functionality. but things get fuzzy

laura: thought SC had to be positive. not use Do Not

awk: this is Guideline not SC

<Greg> If we want to be positive the formulation could be "Provide alternatives to use of device sensors in ways that require physical capabilities of the user".

awk: there are instances of Do Nots in guidelines

<Detlev> do not rely on device sensors for user input

awk: any objection to short guideline

<AWK> "Do not rely on device sensors for user input"

<Greg> Technically, mice, keyboards, and touchscreens rely on device sensors in the broader sense.

<jasonjgw> +1 to Greg's formulation.

awk: "do not rely exclusively on device sensors for user input"

<Detlev> device motion sensores?

gl: prefer mentioning user abilities from SR

<Alex> i think keyboard is device sensor

sr: agree with guidelines

<Greg> Thus I prefer the slightly older version "Do not rely on device sensors in ways that require physical capabilities of the user".

<AWK> "Do not use device sensors for user input in ways that require physical capabilities of the user"

<Rachael_> I prefer a positive guideline as well. A proposed light tweak to Gregs: "Provide at least one alternative when using device sensors that require physical capabilities of the user."

sr: don't want to say "don't use..."

mg: even adding user abilities gets us away from Gregs point about mouse and keyboard

<Alex> even an eye trackers are sensors

detlev: can we qualify device sensors with motion sensors - to include accelerometers, etc

<Zakim> steverep, you wanted to ask if there are logical homes for these SC elsewhere?

<Alex> mic is also a sensor :)

sr: can we move on, and cover this else where. motion sensor covers mouse. it is a complicated issue

awk: <<<sigh>>>

<Zakim> Greg, you wanted to say what we're REALLY trying to get at is allow full use via standard input modalities (mouse, keyboard, touch surface, and equivalents).

gl: how does this differ from others. trying to get at anything that requires "non standard" input other than mouse, keyboard and touch

awk: not today. have tried that previously. We are in operable, have keyboard accessible SC

<Greg> What we're REALLY trying to get at is allow full use via standard input modalities (mouse, keyboard, touch surface, and equivalents). Maybe it's easier to formulate that way rather than to identify all the non-standard input devices.

<Greg> Define "common input devices"?

dtelev: perhaps use "additional" sensor inputs. might cover things other than mouse, keyboard, etc

awk: seem strange to have guideline with definitions. conform to SC not to Guideline.
... just need a simple statement to summarize the SCs

detlev: ok with simple summary

<steverep> "Ensure that device sensor inputs are not a barrier for people with disabilities"

bb: guideline should be in plain language.

<AWK> "Ensure that device sensor inputs are not a barrier for users"

awk: SR is a catch all. perhaps have USERS not people with disabilities

josh: something that can be done with a sensor should be done by other methods from the author. perhaps 'not exclusively by a sensor'

<laura> +1 to "Ensure that device sensor inputs are not a barrier for users"

<Detlev> "Ensure that device sensor inputs are not a barrier for users"

awk: "Ensure that device sensor inputs are not a barrier for users" what do others think

<bruce_bailey> +1 to steveR's text

<Rachael_> +1

<jasonjgw> +1

<Greg> +1

<Detlev> I can live with that although I prefer (do not rely...)

<Ryladog> +1

awk: any objection to "Ensure that device sensor inputs are not a barrier for users"

<JakeAbma> +1

<Makoto> +1

<Mike_Pluke> +1

RESOLUTION: accept as amended "Ensure that device sensor inputs are not a barrier for users"

631

awk: related issues. discussion of size 22x44. how did we get there
... related 261 and 271 (wording change)
... 631 is logic behind 22x44.
... last time close to default text size. discussed with Mobile task force. not totally happy with change.
... suggestions are all over the map.
... any advocate for larger than 22x44

none

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

awk: any advocates for keeping same size?

mg: support as is currently

<Rachael_> +1 to the same.

awk: alastair +1 same
... any advocates for making smaller? 16x44

jason: have no idea what effects are of different sizes on folks with dexterity issues
... what is minimum threshold? don't have lots of empirical evidence on sizes vs user needs. hard to make a decision just to reach a compromise

<Zakim> steverep, you wanted to say I would feel much better if we had some sort of user justification for 22px - is it at least above the lower limit?

awk: similar to GV concern about a special mobile version.

sr: need some justification... 44x44 or 48x48. perhaps

awk: those were too big if talking about links in text. they came from apple and google.

<Zakim> JF, you wanted to ask about the discussion about mandating 44px on only one axis (as opposed to two)

jf: thought we had discussed previously... use only 1 axis. 44 height or width. perhaps a minimum other dimension
... 44px on one axis and minimum font size on other axis.

awk: on mobile, few alternative to touch target size

<JF> propose a measurement that is effectively 44 px X default height setting, agnostic over whether the 44 px is horizontal or vertical

jason: comment questions the rationale of choosing the size. We need to ensure our arguments. back up with what is known about folks with dexterity issues using mobile devices

detlev: comment does not request a change in size. just explain how we arrived at our numbers. and see...
... otherwise remove AA

<Alex> we will test it

awk: any objections to this size?

brooks: won't object. but designers will want to know basis for numbers. need to justify it.

jake: last time, David was questioning if list of links is a block of text. I think 90-95% of links do not have 22 pixel height for text links. almost all sites will have to adjust (all with 12,14, and 16 px fonts)

<AWK> can't hear you alex

<Alex> i will call back

awk: many concerns

mg: questions raise all along. we need to have a justification.

<JF> +1 to Mike, which is why I am suggesting 44 X default text size...

<gowerm> scribe: gowerm

Jason: We need to have solid ground for the values we put in.
... Going back to the issue raised by GregV, it's a difficult one to judge without knowing the parameters under which users can do something

Alex: At MS we have a different approach. We determine the space between the target is the more important aspect, rather than the target itself.
... This gives me stomache pain. We will flush out issues during CR testing.

AWK: So if we put this in as it is and MS and others say 'we don't like it, and here's why', assuming they are well-research, one of two things happens: we exit CR and come back after another period of time, or else we have this item in as at risk, which would result in it being pulled or staying.

Alex: We're running out of time. So, yes, that is the risk. In a long game, we'll resolve this one way or the other.
... We understand the user need.

AWK: Right now we have Target Size and Target Size (Enhanced). The difference is target size and an inline exemption.
... I feel like we don't have any real justification for the size.

<Zakim> gowerm, you wanted to say that John's stance seems like the only defensible one so far

JF: I think the number 44/48 in one dimension has enough material we can point to for one axis. If we say the default font size is the other axis, then we are just saying that the 44 pixel minimum must be met in one direction.
... we are going to have to be able to sell this to people.

<Zakim> steverep, you wanted to say that using only one dimension does not seem to solve anything and only complicates the questions for users

Josh: I like John's idea. It makes sense to me because it is depending on the context. Apple and Google as citations seem defensible. One axis depending on the ratio or view seems defensible.

Steve: The idea of saying only one dimension doesn't solve the issues we're talking about. Does it do anything for the user? Any non-square size, my point is then, what happens on the diagonal.

AWK: Not everything is rectangular though, right?

JF: Can you give us a context for diagonal? Even round links are constrained to the box model.

Steve: I'm not saying it's not presented on the screen without diagonal or rectangular. I'm asking why we can't talk about 44 pixels on the diagonal.

<Detlev> I would go with JF's idea (incl. defaut font size for the other dimension) because I still think it is worthwhile to establish it in AA

JF: We're talking about the width of the default text. Even at the smallest font size, it gives me a target of 8x44.

Steve: Not everything is text.

JF: Yes, but we're saying that if 16 is the minimum, then people should have a minimum of 44 in one direction.

Steve: We don't have any justification to say that.

JF: Can you prove the contrary?
... We're saying if something is good enough for them, we can also say that as well.

AWK: We may find out through user feedback that this size is insufficient. The size people can click on has the potential to be changed by the user agent.
... We've been talking about this for awhile. One proposal is it has to be 44 in one dimension. Another is 44 in one dimension and matches the default font height in the other. Another is to propose to this as 44x22 and indicate that we don't have a justification.

<JakeAbma> +q

GOWERM: Is this getting marked as at risk?

AWK: I think it will need to be marked as at risk if we put it in as 44x22.

Jake: Did we ever have the option of making it 44x44 for everything except text links?

AWK: I know it's been discussed.
... The concerns raised are inline with the same concerns about the default font size. They want all targets to be larger.

<JakeAbma> except text links and interactive elements in a block of text

Jason: One way of going would be to have exceptions in the AAA that are based on user research and drop at AA.

<AWK> Straw poll: +1 for keep as is, +2 for 44 in one dimension, +3 for 44 x default text size, +4 for excluding text links entirely

Jason: What Alex is referring with is relevant. I'm not comfortable making last minute decisions.

<Detlev> +3

<JF> +3

<JakeAbma> +16

<Rachael_> +2 or +3

<JakeAbma> +3 or +4

<Makoto> +3

<Greg> +3 or +4

<steverep> +4 - I was happier with more exceptions and justification that we solve some of the problem

<jallan> +3 or 4

+4?

<Mike_Pluke> +3 or +4

<Alex> +2

<laura> +1 for keep as is and use david’s response: https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues#631

I echo Steve's sentiment

<Ryladog> +1

<Brooks> 0 none of the above

<Ryladog> Unless you rephrase the question

<Greg> I could certainly live with current wording.

AWK: Is there anyone who can't live with it as it is?

Alex: As At Risk status?

AWK: It's going to have to be At Risk
... If we change it in a substantive way, it is also going to be at risk.

<jallan> I like david's response.

Detlev: Is there a high chance this will create a lot of pushback? I would go for the compromise John has suggested.

<Zakim> Brooks, you wanted to ask do we have any evidence that the touch target minimums we are "borrowing" from Apple, Google, etc have been formulated with users with disabilities in

<JF> +1 to Detlev. We can still wait to hear about larger feedback between now and 'then'

Brooks: There's been some research done in this, but I don't see where they come up with 7-10mm size for buttons. But I didn't see anything for accommodating users with disabilities.

Katie: I agree. Tons of research was done by the COGA working group, and so I see a major change as putting it as risk as well.
... We should leave it as is.

Detlev: Arguing that there is not sufficient evidence that it helps users.... It's certainly true that we don't have enough evidence, but we also know it is difficult to hit small targets. That argument alone seems compelling.

Jason: ONe of the implications of what Alex was saying earlier is that you can address this by changing the space between targets rather than the target size. All these things need to be taken into account.
... It seems to me we have good reasons to believe we're going to have to rework this anyway. Do we create a backwards compatibility issue, given we may have to revisit and rework?

AWK: From what I'm hearing, this is what I would propose. Option 1, keeping as is, will be a very high risk.

<Ryladog> ag-sup

AWK: We don't have great evidence as to what is best. We know there will be great variation. So we are trying to define it by something we can hang our hat on, in this case Apple and Google work.
... I'm hearing from Steve that if we just exclude text links, but I also know we've had people want text links to be part of it.
... My gut is that 44 in one dimension is going to cover a lot of ground. I don't think we'll have sites trying to make super small targets.

<JF> +1 there

AWK: I'm leaning towards option 2, which gets us a good way of the way there.
... At the AAA level we can leave it as is... We can look at that in a minute.

<Ryladog> +1

<JakeAbma> https://www.w3.org/2002/09/wbs/35422/resolving_issues_2/results#xq10

AWK: Option 2 is 44 in one dimension.

<Detlev> I can live with +2 as well

AWK: Can anyone not live with that?

<Ryladog> I can live with that

I can live with that.

<steverep> -1

<JF> I can live with +2 as well

<JakeAbma> Can live with

<JakeAbma> can live with 2

<david-macdonald> Prefer 44px on direction

Josh: I am +1 for the second option

<Makoto> can live with 2

<Alex> +1 for option 2

<laura> +1

<Mike_Pluke> +1 for option 2

Steve: I dont' think it is providing benefit. 22 is the biggest issue. Does eliminating the 22 really solve anything? How does that make our comment response better?

AWK: We're looking for something to set a lower limit for target sizes. But we also recognize problems making this work for text links.

JF: By removing 22 we have effectively answered part of the question. We kind of guessed at that. We can put to 44 with the Apple reference.
... By saying a link has to be 44 pixels in one direction, we've gotten close enough to provide tangible benefit

<Greg> I'm really not thrilled with option 2 as 44x8 is not very helpful--and if we weren't worried about authors using small sizes we wouldn't need this SC at all, or would say 8x8 minimum--but I suppose I can live with it.

Mike: There will be other things that control how visible it will be in the other direction. it will never be reduced to no pixels in that dimension.

<Zakim> steverep, you wanted to ask if 31px x 31 px target is acceptable (44px diagonal)

Steve: If we are saying 44 is good enough on one dimension, how about a 31 pixel square image or icon. That gives you 44 pixels on the diagonal.

AWK: That wasn't used in the Apple and Google guidance.

<JF> so we specifically state that 44 can only be height or width, that diagonal measurements are out of scope

Steve: I'm saying if you want to give one number, make it across the dimension of the object. You're finger doesn't care whether it is height or width.

AWK: I think the vast majority of time people are dealing with rectangulars.

<JF> +1 to height or width *ONLY*

Steve: You're saying 44 pixels is justificable because users can hit it.

JF: The 44 pixel justification comes from Google. If you want a single dimension, use a diagonal of 44 x 44, but that would be 60 or so.

David: The point I wanted to make is...

<AWK> I plan to close this out in 3 minutes. We have other items.

David: for the whole question of testing. if we're trying to make people spend their budgets, forcing people to test pixel widths for everything is expensive and not very advantageous. Let's make sure people do things that matter.

Brooks: With front-end designs, I can promise you people will use this to obfuscate legal definitions, etc.

Steve: I'm not saying we need to worry about the diagonal.

<Greg> I agree with Brooks

Steve: Your finger doesn't care whether you're approaching something vertically or diagonally. It has to be in any direction, not just vertical or horizontal.

AWK: I think we hear your point, but we're trying to specify something that is challenging. I don't know that we have the perfect answer.
... The majority of the people on the call are okay with 44 in one dimension as an option. Then you wouldn't have a 31x31 pixel target.
... 44 by text height is possibly a little light, but we need to go on. I understand that you may be objecting to this one. Is anyone not able to live with it?

Brooks: I have serious reservations. If there's anyone else who has disagreements.

David: What if we said something like the minimum would be the default.

AWK: I'm hearing from Brooks a reservation, maybe not as strong as Steve's. i think we need to put it out to CFC.
... Anyone objecting to sending option 2 out to CFC?

RESOLUTION: Send option 2 out to CFC.

1.3.4

AWK: I sent out an email summarizing the comments we've received, as recently as this morning.
... We've got 13 comments on this. A bunch of them are saying there's no implementations, or there are security concerns, or the list needs to be longer/shorter/defined by someone else.
... We've tried very hard to come up with something, and I think it's been very challenging.
... I agree with David that we put it in with the idea of getting better feedback, and we are.

Alex: I think this is a valuable experimentation that should be embarked on.

AWK: What does that mean to you?

Alex: It shouldn't be set out as a requirement. Ask a small subset of people to do something and see if it works, before we set forth and say everyone should do this.

AWK: So for 1.3.4 that would move it to AAA or a later release?

Alex: yes. If we can talk about it outside WCAG, we can talk about it. I'm a little concerned about the viability. How can it exit CR? We can go through the motions, but I don't see how it can exit.

JF: I'm quite emotionally invested in this one. Alex I hear your problem. This is a chicken and egg problem. If we put this into AAA, we'll get zero traction.
... The list is a reasonable list. it's based on observation and research.
... It's building off of existing technology. We need to be careful, and part of the problem is that just like 4.1.2... We can use Microdata and schema.org annotation.
... We have all the pieces. it's just about stitching together.

Jason: I've discussed this with colleagues, who share some of the concerns in the comments. An additional concerns lies with worries that if this would proceed, it would lead to bad and inconsistent implementations.
... That applies to 1.3.4 and 1.3.5. My colleagues and I have significant concerns with these proceeding.

Alex: Replying back to John, I get it, but we can't get back to the point of benefitting users is that there is no personalization part. We need to do small experiementations, but not in WCAG.

<Detlev> +1 to Alex

Alex: What would that AT look like. It's a huge leap between someone putting that in, labelling properly, etc., from helping end users understading what they are doing. That's too big a leap. using schema.org, no problem. But we need to cross some more bridges.

JF: We had the same problem with 4.1.2. Where ARIA wasn't supported anywhere. But we still took that leap.

<AWK> AWK: for 4.1.2 it was still possible to conform using standard widgets

JF: I appreciate taht problem too. I've got an engineer at Deque working on proofs of concept. you're right, we have no tools. But we need a corpus of tools. I agree it is early on. it is still experiement. But 9 years ago we had the same issues with 4.1.2

Mike: You say the list of terms is based on reserach. What research is that based on?

<Zakim> Makoto, you wanted to share dilemma in Japan

<Ryladog> Just want to point out that 4.1.2 was not about saying use ARIA, but rather ensure that name, role and value of the AAPIs is utilized. But I understand the point

<JF> @ryladog, exactly, but the conundrum is very similar

Makoto: If this become an ISO standard, it could create an issue because Japanese must be identical to ISO. I translated everything and encouraged people in Japan to send their comments. After publishing my translation, I got a bunch of negative feedback on this criterion.
... They are saying it may be feasible but it is not easy. It will be time consuming. They will not do this because there is no user benefit. if there are no user agent support, then they cannot test it. They don't support at AA. At AAA they can support it.
... If 2.1 becomes an ISO standard, this criterion at AA will be a huge impact in Japan. I'd like to avoid the worst scenario. I'm facing a difficult dilemna.

JF: Where to start? Let me go back and address Mike's concern about research.
... There are two parts. We might consider splitting this apart and focus on the form inputs. The form inputs are focused on the html5 autofill inputs.
... That was a direct 1:1 mapping. In terms of the controls, we looked at common functions. We also looked specifically at authoring content and online email. Finally, we also looked at real basic functions of shopping carts.
... We tried to take a holistic view at what we commonly used. The research was adhoc. We went off and did some woodshedding. David macdonald, Chris, myself and Lisa Seeman took part. The research was adhoc. There's no formal documentaiton.
... Makoto, you're right. In terms of implementation, it's just code. it can be pretty easy to do.

Jason: I've engaged in a discussion on the mailing list of what John is talking about confining it to autocomplete.
... One could make an argument that autofill is cognitively useful, and that a techology exists.
... Based on what JF was saying in regard to 4.1.2 and ARIA is not accurate. We have signficant user agent support. We had accessiblity APIs in the desktop. We don't have anything like that in place for the advantages of this proposal.
... We have concerns about how effective this proposal would be. i can enter into those details.
... reducing it to just the autocomplete is possible, but I think we should acknowledge this is experiemental

<Zakim> gowerm, you wanted to say there are challenges with testing synonyms, and the 4.1.2 analogy is not perfect.

<AWK> Gower: real difficulties testing the set of terms

<AWK> ... they need to look at every link/control and make sure that it is aligned with the right term

<AWK> .... non-trivial exercise

<AWK> ... try with any random 10 pages from the web

<Detlev> +1 to goverm

<AWK> ... re: 4.1.2 you met with HTML

AWK: I want to get a sense of the room here. We're not making a decision.

<AWK> +1: keep in, -1 for needs to be removed or moved to AAA

<Alex> -1

<Brooks> -1

<Ryladog> -1

<JakeAbma> -1

<Detlev> -1

<JF> +1

<jasonjgw> -1

<Makoto> -1 at this moment

-1

<laura> -1 for now

<david-macdonald> +0 I'm open to limiting to HTML auto complete on forms

<steverep> -1

<AWK> -1

<Mike_Pluke> -1

<Greg> +0

<AWK> Type +1 if limiting to HTML autofill options would change vote

I think that we can actually achieve this goal with the existing programmatic material, as long as we get a properly drawn out list of terms and synonyms.

<Ryladog> +1

<JakeAbma> -1

<david-macdonald> +1

<Detlev> -1

<Brooks> -1

<jasonjgw> maybe

<Makoto> -1 (move to AAA)

<Alex> 0 depends on the text

<AWK> -1

<steverep> -1

<Mike_Pluke> -1

0 I'd need to see text

<david-macdonald> In content implemented using markup languages, for each user interface component that serves a purpose identified in the Common Purposes for User Interface Components section, that purpose can be programmatically determined, except where the control is not implemented using standard elements.

trackbot, end meeting

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/presume/require/
Succeeded: s/"o not/"Do not/
Succeeded: s/stitchign/stitching/
Default Present: AWK, JakeAbma, Detlev, bruce_bailey, Laura, Greg_Lowney, Makoto, Katie_Haritos-Shea, jallan, Brooks, Alex, SteveRepsher, jasonjgw, Rachael, JF, Mike_Pluke, MikeGower, david-macdonald
Present: AWK JakeAbma Detlev bruce_bailey Laura Greg_Lowney Makoto Katie_Haritos-Shea jallan Brooks Alex SteveRepsher jasonjgw Rachael JF Mike_Pluke MikeGower david-macdonald
Regrets: MichaelC
Found Scribe: jallan
Inferring ScribeNick: jallan
Found Scribe: gowerm
Inferring ScribeNick: gowerm
Scribes: jallan, gowerm
ScribeNicks: jallan, gowerm
Found Date: 10 Jan 2018
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)