Accessibility Guidelines Working Group Teleconference -- 02 Jan 2018

<jallan> scribe: jallan

<Joshue108> trackbot, start meeting

<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 02 January 2018

awk: count down. have next 2 weeks to resolve comments.
... 3 CFCs open. please respond
... accessible authentication, interactions, id purpose are the CFCs

<Zakim> laura, you wanted to say do we need “designed to give the impression of motion or scaling” or could we remove it?

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

150

graphics contrast. unanimous accept

RESOLUTION: accept 150 response

619

<Glenda> Question: does this mean I should move foward with the 150 response as written? Or do you do that?

response 5 for, 1 nay

mc: will we look for close issues with the lable?

awk: yes. defer label
... indicate in response label as DEFER

awk edited response. https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues#619

mc: will put link in GL page

awk: any objections?
... as amended

RESOLUTION: accept 619 as amended

awk: will send responses through CFC. then AWK will send responses

620

Motion actuation - results: 4 yes, 2 no

awk: seemed to be confusion between user motion and device motion. perhaps change language

<Detlev> @AWK: sounds good to me

"user movement as interpreted by device" anyone have any ideas for better wording

scribe: vis a vis - device motion vs user motion

jw: user motion interpreted by device, and keyboard operable... if not directly operating a UI component...

awk: movement interpreted by camera, shaking device, etc would be allowed.

jw: detection of user motion... may be good wording

detlev: +1 to awk wording

awk: historically, wary of referencing user (device, environment, abilities).
... this may be a bit different. detection of function vs user ability

josh: reached out to Suzanne. seems open to helping on wording

<AWK> "Functionality which can be operated by detecting user movement can also be operated by user interface components and can be disabled to prevent accidental actuation, except when:"

awk: above wording may help
... do we need to make this change? is it better?

josh: this is the first of many issues from Suzanne. I'd rather keep the scope of the SC focussed rather than being too broad and hard to parse for authors.Acknowledge heads up to series of issues.

sr: current lang seems better. device is observer.
... device is detecting user motion. new wording inserts a different observer. it doesent matter who moves the effect is the same.

detlev: both should be included. shake device or camera view movement. new wording covers both

jw: don't need to distinguish between motions (device/user).
... regardless of overlap

awk: part of comment is position of user is not considered. part of response in 619

jw: satellite navigation would fall under what we have. do we exclude case. or adjust manually

<Zakim> steverep, you wanted to go back to 619

jw: detect user and device motion. perhaps ... user motion relative to device as opposed to uniform motion of both

sr: talking of scale. distinguish between position and motion. what is author requiring of input. position doesn't matter. what you are requiring user to do by motion is the issue.

awk: reads 619.

sr: it only require position, it does not apply

detlev: differentiate user motion (intentional) is important. just position does not apply.
... virtual fountain, pointing device at fountain is intentional

awk: first two sentences seem to contradict each other?

detlev: will need to review. perhaps remove first sentence.

jw: gestural input (camera) - position of user over short time. positioning (gps) motion over time. depends on time scale.

<alastairc> Seems like a lot of types of motion, do we need to separate them? "... can be operated by physical motion" might work better?

jw: long time could be inbounds in the SC. unless add a time scale constraint

sr: 619 draws important distinction. if you must be in Australia to move to next step - a different issue. but orientation of device is different. it is a good question.

jw: example: different interface when you board a bus than when you are stationary.

awk: getting on bus is a proximity sensor. could be in same place on or off the bus. yes 619 is a potential source of confusion.
... jw time scale is also an issue.
... did we intend this to cover geographic location?

awk: edit to exclude geographic location does not apply. point to fountain would apply.

awk to edit

RESOLUTION: Accept 619 with additional edits.

awk: 621 and 22 are all related to 620. do we need different wording to wrap all together.
... get a volunteer to suggest an edit and talk on thursday.

jw: I will review.

awk: issue around geographic location.

sr: talking about motion was to get away from positioning. tried to scope down. this is a tough SC.
... limitation on user input is huge.

awk: perhaps a Note?

sr: yes

jw: disagree with SR. problem is detection of motion by change of location. problematic time scale.

<Detlev> If it helps I am happy to draft an exception for position - but may not be on Thursday's call

jw: there is a problem, geographical position to determine motion.

awk: don't think we were taking about functionality that only works on a moving train as determined on long/lat coord

detlev: not covering positioning related movement. may be an edge case. may need an exception. Not on Thursday

awk: if we clarify with Note. non normative. this is about user motion and not position. with example. app over time may determine user is moving over the earth. this is not what SC is focusing upon

<Zakim> alastairc, you wanted to ask if the term "physical motion" / "physical movement" has been considered

jw: not comfortable

ac: 'physical motion/movement' as alternative wording?

awk: doesn't work.

<steverep> me

awk: I will try to come up with options.

<Detlev> can die feedback

jw: me too

<Detlev> give

RESOLUTION: leave 620 -22 open

630

awk: content on hover or focus
... MG wrote response. liked last point. move the last point up one to cover last two points
... any other thoughts.

sr: MG and I reviewed this closely. last point can be answered by Understanding doc example. response needs updating. Example 2 covers last point

awk: seems similar to 2nd to last response

sr: reordering is good

awk: 630 edited
... objections?

none heard

<alastairc> nope, +1

RESOLUTION: accept 630 as amended

631

awk: why 44x22

<david-macdonald> I'm fine with that amendment by Awk

awk: non inline text links are an issue.

<Joshue108> +1 to that also

awk: some minor edits

mc: should be in Understanding

dm: agree with non inline text links

<alastairc> Fitt's law is the only actual 'law' in psychology: the bigger the hit area the quicker it is to aquire. So the size comes from feasiability, not user-research.

jake: exception for inline. unordered list with text links is covered. regular text links are 17 to 20 px high. discussion of font size and padding.
... split 44 in half. add padding without changing line-height will overlap links in a list. may need some adjustments. need examples

awk: if we attach height to text link with browser default text size then ok.
... VERY concerned given timeline. need to get this right
... 22 need to give users a larger area.

jake: issue with esthetics and overlap. developers won't agree for sizes under 16

awk: any bulleted list

david: sees list of links as a block of text

josh: understand jakes concerns. doesn't work as one size fits all. documentation to help understanding

ac: answer to comment. bigger is better. FITS law.
... numbers from feasibility, not user research. user research would say bigger

<david-macdonald> Inline The target is in a sentence or block of text;

awk: concerns about justification. seems arbritrary.
... make it based in reality, browser font size.

<alastairc> Does anyone want to change the response?

awk: can folks live with it currently one way or another.

david: what is the requirement? length is important. Height is an issue. sees many ignoring this SC because of height issues.
... response. data says it should be bigger. so making bigger but make devs happy. horizontal vs vertical size is the issue.
... if more that x links than the requirements morf.

jf: long discussion. with jake and david. restrictions on height. what if - height is no less than the default font height on page.
... allows height to float, but width has a minimum

awk: if, no less than default height...

jf: css-reset. have a requirement to allow for zoom. minimum height is default height of page, and be zoomable. it meets the use case

ac: default font size is 16px. measured size doesn't change by family. line-height is critical. complicated terrritory

<alastairc> scribe:alastairc

AWK: I would rather say a number, rather than reference a default text-size from different browsers. So in normative spec have 18, 16px, whatever. Then, is that everying, or non-inline text links?
... Any thoughts?
... what would the number be?

JF: Should be the same height as the default font. Hooking to the default font-size makes it scalable, an easy ask of authors. It addresses all the use-cases I can think of.

Mike_Elledge: John has a good point, and would automatically adjust according to the person's CSS. I'm assuming that if someone make their font-small they still have to have that 16px in the browser?
... should we make that clear? If not, should we set a floor, and the floor is below/at the 16px level. Increases on a relative basis, but doesn't decrease below that point.

jasonjgw: It seems that we need a user-agent / AT solution, as the more exceptions /reductions in target size we get, the harder it gets for someone with a motor disability. We used to have an exception allowing for AT solutions, that disappeared around TPAC.
... it seems that we need a UA/AT level approach, given all the exceptions/limitations we are asking for.

<JF> +1 to "One axis being 44 px"

<JF> or rather 44 X 'default height'

david-macdonald: What if we ask for 1-axis to be the 44px? Then you don't have many of the issues. Naturally most people would use 44 by the default height, testing easier, impact on user minimal.

Brooks: This is mute if the person is using a keyboard or similar? So in the response, need to say what the accomodation is about, needing to use touch or similar.

<Greg> Brooks, benefits include for those with impaired vision as well as those with impaired dexterity.

Brooks: I know we're concentrating on the number, but for this response, need a fuller answer.

Greg: Remember there are benefits for low vision to.

AWK: Harder to associate that benefit with low vision, doesn't require the text is larger.

Detlev: Specifying only one dimension doesn't seem sufficient. Main use-case is people on mobile with big pointers (fingers), so I'd still suggest a minimum vertical dimension in the SC text. Having it like JF suggested is an option, but in major browsers that 16px is default, then perhaps use 18px?

<Jon_avila> Agree with Detlev we need minimum for controls like sliders and grips for resizing.

Detlev: in future the default size might change, so perhaps more future proofed to put in a fixed size.

AWK: How many people couldn't live with the change to the primary text? E.g. size is 44px by 16px, except when...

<JakeAbma> +1 to 16

<Kathy> -1

<JF> +1 for changing from 22 to 16 px

<Detlev> better than no requirement...

<KimD> Not sure - would we keep the exceptions?

Better than nothing. Doesn't seem to be required by the comment though.

<JF> (although I'd prefer we use "default font height" instead, with a note that the expectation is no LESS than 12px (for the footnote issue)

Kathy: What are we solving? If we move it down even further, need to research as it might not be helping anyone.
... if someone has mobility challenges, is this enough?
... had these concerns when we dropped it to 22px, all of the requirements / SC should be driven by user-need, and would like to know if we help users at that level. Understand the challenges, we want to do something, just not convinced it will be helping.

<Detlev> alastair is right that the comment did not ask for a reduction, just a rationale...

jasonjgw: That was my thought as well, don't know what the effects would be. Don't think that helping someone, some small range of use-cases is enough, needs to address an accessibility problem in a substantial way. I don't have numbers, or know where to get them that would tell me the needed dimensions.
... need to step back and consider with UAs as well if we get push back.

<Zakim> JF, you wanted to ask about "square 'footage' measure"

steverep: echo Kathy & Jason.

JF: Just trying to think about it outside the box. If I multiply 44x44, 900px... [missed some other examples], should we do this by square pixels? So the author has to meet a minumum square size.

<steverep> No, because a person can't change the aspect ratio of their finger

<Zakim> Joshue, you wanted to agree with Kathy

<JF> @steverep, no, but they *can* zoom the content

Joshue: Echo Kathy, concerned that by diluting it down, it would be a weak step. Where we need a larger hit area we should, but there are places that dont' care about that.

<Brooks> I think we need to include in a response the case of who will benefit from this SC for Target Size, who are not already using a non-pointer form of input (for example, keyboard input).

Joshue: I would rather see something there that's substantial, rather than there for the sake of it.

<Jon_avila> I don’t think squee pixels will meet the need

David: Even 44x44 is less than half of what some people need (which is around 100x100), so going to 22, 16, or square area... any of those are huge compromises. The better aspect is that people can zoom in with the other SC now. Even back at 22px, wouldn't help those users who need 100px, people who shake when trying to put finger down.

Mike: could we leave AA for study, and agree a AAA number?

AWK: Have that already, which would be the next thing to change if we needed to.
... Got a comment that came in, asking about the requirement's justification.
... we've been conformtable with 44x22 so far. We've had similar comments, will probably come up again. Should we go with David's response?

jason: I'm fine with that as a response, but don't like the arbitrary nature of the values. Not happy going to CR with arbitary values where we dont' know what the impact will be.

<Detlev> +1 for keeping it in CR and see what the responses will be

AWK: We could keep it as-is, and provide the rational. Like we did with the 4.5:1 ratio in 2.0.
... it came down to the number of combinations available, could have been 4 or 5, compromised on 4.5.
... How do we respond?

+1 for response, if we water it down futher, not worth spending time on, ditch it. (Channeling Patrick)

Brooks: It is about saying that keyboard access alone isn't enough, need to empower touch access.

AWK: can put this to one side, get back to it later.

RESOLUTION: Leave open, will get back to it later

624

AWK: this is about 1 item in the list: compose. It should just be new, e.g. new folder, document etc. Rather than just compose, which would exclude folders, it would be broader.

Couple of items related to 1.3.4 that we need to discuss.

<Zakim> JF, you wanted to suggest that "compose" implies either keyboard or voice input - is more specific

JF: there's a specific difference between composing, and creating something new. Could be to compose things on the keyboard etc. It's about invoking some text input, speech input. Not about creating a box, but filling the box.

AWK: The description talks about creating something new.

JF: Might need to rework the text. It is a distinct thing from creating something new.

<david-macdonald> Yahoo, Google use compose, outlook uses new

JF: all about the user finding buttons, so we'd like to be as specific as possible, and use verbs. There's a control to perform a function, so here it is similar but different.

david-macdonald: Is that because outlook combines email/calendar/contacts etc?

<david-macdonald> right

AWK: New doesn't seem to off-base, and compose would be applicable. I can see the point that 'new' might make more sense, if you have edit next to it.

Jason: It can be confusing, so file browser has a 'new file', then it promts you for the name. Can prompt you file it in, but can be confusing. Challenge here is that the context will be different, so it is how much it affects the user.
... with a short, fixed list it will help to a point, but may not fit all interfaces / use-cases.

<JF> agree with Jason, we can *add* a new term of "New"

Jason: happy with both as separate concepts, and show the distinction. So could have the create, and the create & edit functions.

AWK: If we were adding new, we need a definition [description], and we'd need to change the current description of compose.
... Do people prefer to change compose to new: +1. If you prefer add, give me a -1

-1 (add)

<Detlev> -1

<JF> -1

<alex> +1

<JakeAbma> -1

<AWK> +1

<Greg> +1 I think Compose can be on the same page as New, so distinguishing them is potentially useful.

<jasonjgw> -1

<kirkwood> -1

<KimD> +1, assuming there's not an internationalization reason "compose" was selected

<david-macdonald> -1

<Glenda> -1

<Greg> Sorry, -1 I think Compose can be on the same page as New, so distinguishing them is potentially useful.

<AWK> https://www.w3.org/TR/WCAG21/#commonpurposes

<JF> ACTION: JF to write a new definition for "new" for https://www.w3.org/TR/WCAG21/#commonpurposes

<trackbot> Created ACTION-341 - Write a new definition for "new" for https://www.w3.org/tr/wcag21/#commonpurposes [on John Foliot - due 2018-01-09].

RESOLUTION: Leave open pending JF edits.

Comment about needing an identifier for common control concepts

<Detlev> and make it CP + three digits...

AWK: That's one peice that's important for standards work in EU. Didn't seem controversial on list, does anyone in the call have any concerns? CP, common purpose & 3 digits would be fine.

<JF> +1 to adding a numeric (or alpha-numeric) identifier to each of the Common Purpose controls

<Joshue108> ideally it will somehow reflect that purpose.

RESOLUTION: Add an identifer for each common purpose

<Zakim> steverep, you wanted to say we'd back ourselves into the same corner as with the SC

steverep: If you add numbers without gaps, makes it harder to add to later.

<Joshue108> Ok, thanks JF!

JF: We've grouped conceptually, but doesn't matter about the order really, we can just add to the end.

<Joshue108> Sounds good.

steverep: Whether it matters depends on the reader. Some readers will find it easier when grouped in concept has a logical flow.
... this was the order around the SCs in the first place.

david: If we have different groups, e.g. with first two letter different, then that should be sufficient.

JF: Not sure I understand? Do you mean different alpha-numeric numbers per group? Oh, for inputs/links/buttons.
... sure. To me, the whole point is we have a fixed list of conceptual ideas. If we get too granular/specific, then doesn't help. The AAA version is 'label everything', this one should be more focused. Steve, understand your point, here we've re-grouped by testing method.
... not to worried about it, once numbers people can slice and dice as people want.

Steverep: I can live with it, just saying that if it is 1,2,3... then need to delete one, it's harder to re-order.

JF: We'll have that problem whatever scheme is used, as soon as we number it.

AWK: Need to wrap up. I'll present some options. The plan now is for people to respond to things, and we have 3 calls left that are scheduled.

<JF> CSUN F2F?

AWK: We might want to schedule another (2nd) call next week. Will also survey about a F2F at CSUN.
... Thanks all, watch your email...

trackbot, end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

02 Jan 2018

Attendees

Contents

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

150

619

620

630

631

624

Comment about needing an identifier for common control concepts

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output