W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

16 Jan 2018

Attendees

Present
AWK, Detlev, JakeAbma, JimA, Kathy, KimD, MichaelC, alastairc, bruce_bailey, kirkwood, Joshue108, Rachael, Greg_Lowney, alex, marcjohlic, SteveRepsher, Laura, jasonjgw, shadi, Judy, Mike_Elledge, Glenda, MikeGower, chriscm, Makoto, Katie_Haritos-Shea
Regrets
Chair
AWK
Scribe
jallan, gowerm

Contents


<jallan> scribe: jallan

awk: we will spend 15 min per item. be efficient and concise
... please don't speak for longer than a minute

open item 1

awk: lots of traffic on this.

<AWK> AWK's suggestion: In content implemented using technologies with support for identifying the expected meaning for form input data, for each user-specific input field that has a purpose that maps to any of the [link]HTML 5.2 Autofill field names, the meaning of the input field can be programmatically determined.

awk: not much concensus. people want something in document
... reviews suggestion
... if there is no support for something then you don't have to do it.
... fields are user specific. individually.
... use HTML list. there is implementation for already. don't have to justify. we don't have to make a new list.

<Zakim> alastairc, you wanted to say generally agree, would just prefer that the list is in WCAG, and the technique makes the link to HTML5

awk: 15 min per item. be brief. we need to decide. Will be putting out CFC tomorrow

ac: generally agree. would like the list in WCAG, even if same list.
... can live with it if list is in html

dm: +1 with caveat about technique on email list.

<alex> can somebody please add the link to SC text to IRC again?

<steverep_> What's the language we are talking about now?

<alastairc> Reposting AWK's suggestion: In content implemented using technologies with support for identifying the expected meaning for form input data, for each user-specific input field that has a purpose that maps to any of the [link]HTML 5.2 Autofill field names, the meaning of the input field can be programmatically determined.

awk: could add metadata in image rather than alt. but more work to get info to the AT. similar to autofill

david: +1

lisa: don't understand whats going on. Was at risk. found implementations. want to keep at risk label. worried about it being pulled out.

awk: lost how much of original intent?

lisa: lost 90-99% of intent the SC
... as of a week ago.

awk: noted.

<AWK> Current proposal: In content implemented using technologies with support for identifying the expected meaning for form input data, for each user-specific input field that has a purpose that maps to any of the [link]HTML 5.2 Autofill field names, the meaning of the input field can be programmatically determined.

jason: current SC has limited functionality as it relates to original. will have trouble supporting current version. don't see benefits

jake: agree with jason. we have lack of time. current SC has limited utility.

<Zakim> steverep_, you wanted to ask if this restricts the HTML technique to autocomplete? Is schema.org microdata out?

sr: reading the SC as using HTML autofill. and Schema.org is out.

awk: schema.org could be a technique if there is browser/AT support.
... easy way to meet is with autofill.

sr: seems we are requiring software without the software.

awk: there is support today. and some benefit. that is the challenge.
... having a field and having help filling out the field. some support exists today may be different from tomorrow. but have the start somewhere.

<Zakim> AWK, you wanted to speak to why this SC may be removed, in response to Lisa

sr: so autofill, but not personalization.

awk: start somewhere.
... response to Lisa. we have 15 to 20 comments that are not all positive. we need to change the SC to meet the comments. need consensus.

lisa: lot of positive feedback. they wanted more. Negative feedback had easy answers.
... like no AT. we are working on.
... no easy answer to security risks - autofill. we will do an audit and remove items if security risks.

<Zakim> gowerm, you wanted to say that my concern is restricting this so much

awk: any other comments?

gower: want to be non restrictive. so not just talking about autofill. need meta information. need to map meaning to attribute value.

awk: was there a suggestion?
... can you live with current language?

gower: yes. but think we should consider other suggestions.

awk: there are testing concerns. and items without lists are problematic.
... straw poll

<AWK> Straw poll: +1 if can live with proposed language, -1 if not

<marcjohlic> +1

<Kathy> +1

<AWK> +1

<alex> +1

<Greg> +1

<david-macdonald> +1

<laura> +1

<jasonjgw> -1

<JakeAbma> 0

<Detlev> +1

<KimD> -1 (just not ready)

<alastairc> +1

<bruce_bailey> +1 that i can live with it

<Joshue108> +1

+1

<gowerm> +1 I can live with it

<Glenda> +1

<kirkwood> +1

<Rachael> +1 to get something in but I have concerns

<Mike_Elledge> I don't see the wording, but I'll go with the group...

lisa: abstain

RESOLUTION: leave open 1.3.4

<alastairc> Can I make a last-ditch proposal this evening?

awk: send out for CFC?

<alastairc> which is daytime for you!

lisa: CFC to remove original wording so we have a record of why they objected.

<AWK> Straw poll: who would be ok with the current language going to CR (+1) and who would not? (-1)

awk: we don't have time.

<marcjohlic> +1

<Rachael> +1

<AWK> "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."

<marcjohlic> oh - sorry - i thought you meant proposed language.. revote

<KimD> -1

<marcjohlic> -1

<alex> -1

<KimD> -1

<AWK> -1

<gowerm> -1

lisa: have proposed responses for all negative feedback.

<david-macdonald> +0

<bruce_bailey> -1

<JakeAbma> -1

<Joshue108> +1

<Rachael> +1

<Detlev> Not sure about alternatives so 0

<jasonjgw> -1

awk: if we pull it out, it is because we could not reach consensus. we will review for a future version of WCAG.
... we need to have all CFC out by end of tomorrow. then 48 hrs to review. done.

<alastairc> I was intending to adjust the current (AWK) verison very slightly, and make sure there are answers for all the comments...

awk: alastair has to get it out soon. and no one has objections. We just don't have time to discuss and hammer out

zakim: open item 2

Target Size Proposals

awk: had sort of agreement on 44px in one dimension. lots of discussion
... did not pass CFC.
... text links are a problem. 44x44 will not work

<alastairc> Kathy's proposal: "The size of the target for pointer inputs is at least 44 by 44 CSS pixels or is at least 26 by 26 CSS pixels with 8 CSS pixels spacing between targets except when:"

kw: put out an alternative. Microsoft min size with padding. do we know status of comment

<alastairc> "Equivalent - The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;

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

<alastairc> User Agent Control - The size of the target is determined by the user agent and is not modified by the author.

<alastairc> Essential- A particular presentation of the target is essential to the information being conveyed;"

awk: google material guidelines also had spacing guidelines.

alex: why eqiv only 44x44 and not spacing.

kw: I missed it.

<alastairc> Update: "Equivalent - The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels, or or is at least 26 by 26 CSS pixels with 8 CSS pixels spacing between targets"

<alastairc> NB: It exempts inline links, so don't have to worry about font-sizes per-se.

kw: 26x26 is 7 mm, 44x44 is 9 mm depending on screen size.

mikee: what is the need when things are inline. what is spacing requirement for inline.

<JakeAbma> had a response for the in-between sizes

<JakeAbma> I would like to check this a bit further as this directly raises the question of different implementations. Don't have lots of time today but here a plain example of links in lists: See https://codepen.io/Jake-Abma/pen/xPNVWx I have 3 lists with links, all with mandatory added padding otherwise I have not enough height for the 26px. Beneath the list items I have 8 px margin because this is also mandatory, so all lists are save... nice. BUT, If[CUT]

ks: inline is excluded.

<JakeAbma> BUT, If I have a target size of 34px height for my links (26 + 8) but no spacing in between (like this one better, no flicker when hovering) this is a fail, even 35, 36, 37... etc will fail...?! Also I've checked with a couple of designers and they won't like it because at 12 and 14 the distance is just a bit too much. When we're going this way we should at least define links in lists as part of a block of text.

mikee: discussion about inline spacing.

kw: inline spacing covered in AAA, exempt in AA

jake: problem with SC. designers not happy. how to deal with gap.

kw: min size without padding .... menu links need more spacing. padding around item. padding is not clickable.

<alastairc> I'd guess that having the spacing helps the touch-deivice algorythms determine which link you meant?

<Detlev> Equivalence would be target size of 8 + 28 + 8 = 44

kw: spacing for menu links, 26px, and have 8 px spacing not 16. its not additive.

<gowerm> You should clarify in the Understanding that the 8 pixel buffers are not cumulative in a list

kw: trying 2 different options. spacing between or different sizes.
... give designers different options.

<AWK> There are plenty of examples of nav bars with items that have no space between

dm: concerned about mega menus, dropdown menus. desktop menu may get lots of pushback. much larger that previous 22px.

kw: have research to back up our numbers. none for 22. we have lots or research for minimum of 26px.

dm: would like exception for desktop. also concerned about padding.

<alastairc> spacing means a space (without hit area) between targets.

kw: need spacing around time. see understanding.

awk: 8 css px around item

detlev: need 28 +8+8 to make 44. that is alot for dropdown menus

kw: padding is minimum.

detlev: odd that spacing changes depending on type of element.

kw: could change 44 to smaller number

alex: MS tested for error, not hitting target.

awk: poll

<alastairc> Kathy's proposal: "The size of the target for pointer inputs is at least 44 by 44 CSS pixels or is at least 26 by 26 CSS pixels with 8 CSS pixels spacing between targets except when:"

<david-macdonald> -1 I want to exempt or lower for desktop mega menus...

<JakeAbma> -1

<AWK> Straw poll: can people live with the current proposal? +1 if yes, -1 if no

<Rachael> +1

<david-macdonald> Items added to the report above

<alex> +1

<Kathy> +1

+1

<laura> +1

<Glenda> +1

<jamesn> AA or AAA?

<gowerm> +1 I'm worried that the spacing needs more explanation and could lead to some issues

<Detlev> +1

<Greg> +1

<bruce_bailey> +1 can live it

<alastairc> +1, I think even mega menus would be ok

<marcjohlic> +1

<jamesn> -1

<david-macdonald> -1 I want to exempt or lower for desktop mega menus...

<Joshue108> 0 I agree with David about mega menus

<Mike_Elledge> +1 with consideration of mega menu issues

<kirkwood> +1

<Kathy> The size of the target for pointer inputs is at least 26 by 26 CSS pixels with 8 CSS pixels spacing between targets except when:

<JakeAbma> -1 multiple issues

awk: trying to strike a balance between all research and user benefit.

<david-macdonald> Add an exception "there is a setting which provides these values"

jake: issues with kathy's other proposal above.

<david-macdonald> The target is available through an equivalent link or control on the same page that is at least 44 by 22 CSS pixels; Inline The target is in a sentence or block of text; User Agent Control The size of the target is determined by the user agent and is not modified by the author. Essential A particular presentation of the target is essential to the information being conveyed;

awk: James concern?

<KimD> 0 because I'm not sure what happens to readability when you have an icon mixed in with text or links not in a block of text

<Ryladog> +1

<david-macdonald> me too on drop downs

james: drop down menus. will be too much space

kw: not 8 on either side. only 8 between.

<Greg> David, isn't that scoping implicit in all SC? For example, .4.3 does not prohibit providing an option for lower contrast.

kw: link 26 then 8 to next link = 34

james: not comfortable. need to do more research.

<david-macdonald> what about "default size" on the onther axis

awk: this seems to be best operational SC

The size of the target for pointer inputs is at least 44 by 44 CSS pixels or is at least 26 by 26 CSS pixels with 8 CSS pixels spacing between targets except when:

The target is available through an equivalent link or control on the same page that is at least 44 by 22 CSS pixels; Inline The target is in a sentence or block of text; User Agent Control The size of the target is determined by the user agent and is not modified by the author. Essential A particular presentation of the target is essential to the information being conveyed;

close item 1

<david-macdonald> Yes I could live with that

kw: if viewport greater than x pixels exemption. people live with it?

<marcjohlic> +1 to working in viewport in some way

<david-macdonald> Exception: the viewport is larger than 99css px

<alastairc> Suggest: except for viewports with a maximum length (height or width) of over 1000 CSS pixels

<alastairc> iPad standard is around 960

kw: talking about mobile and tablet interfaces

awk: what does this mean in reality.

<Detlev> building a breakpoint that increases target offset below 1000 px

kw: iPad pro would be eliminated.

sr: how is author supposed to know. seems similar to orientation SC.

<david-macdonald> to say... it would be specified in the CSS breakpoints

awk: would need to know size. if you query browser. not window size but device screen size.

<alastairc> It is fairly CSS specific.

mikee: define now. or some other mechanism.
... if you have responsive design. build into breakpoint

<jnurthen> upon a little research I think 34px is probably ok for menus. It is the size of the menu entries in the aria authoring practices and it is just about small enough to allow enough flexibility

dm: I can work with this! clients would except.

RESOLUTION: leave open Target size.

close item 2

Graphics Contrast

awk: lots of discussion. 6 open comments.

alastair: written responses with change requests.

awk: major concerns?

alastair: some were pre TPAC. things have changed since then.
... comment about high contrast, but don't know what to change.

<Zakim> steverep_, you wanted to ask if 44 came out of Microsoft too? and to

<david-macdonald> @Steve no 44px from Apple

alex: highly subjective per testers. We will investigate in CR process.
... high contrast. different settings by OS. if HC on website, likely to have it on the OS.
... what if graphic passes on high contrast setting but not on regular setting.
... white or black background example

<Zakim> alastairc, you wanted to say that it doens't impact embedded images

alastair: tested with windows and OSX. impacts controls. doesnot impact imbedded images.

<gowerm> scribe: gowerm

Alex: I wish I could share the screen shots... I makes it hard to share on a list
... I'll post a link

<Joshue108> put it in GH

<Joshue108> thanks

AWK: If you log into github, you should be able to put the image in.

Alex: Subjectivity is the key problem.
... If I have an icon or graph and give it to 10 testers, are they all going to come up with the same set of tests?

<alastairc> As per the comment, is that something we can address now, or as the next part of the process?

AWK: How do other people feel?
... I think we haven't had time to review. Some of the comments are 'we don't like the term' or 'we want the name to be different'

<david-macdonald> +1 non -ext contrast

<Ryladog> +1

AWK: What looks like the winning name is Non-Text Contrast. Does that seem agreeable to people for a broader term?

<Glenda> +1 to Non-Text Contrast

<Detlev> there have been some more votes to option 1 I believe

AWK: I'm going to take that as a 'yes'
... I'll send an email to request reviews of responses.

<Joshue108> +1 to non text but preferred user interface...

<alastairc> probably the most contensious response: "Thank you for your comment. The term graphical object was selected to be generic as it covers a wide range of parts of graphics. Defining the term object (beyond the current text or the dictionary definition) does not appear to help. However, the Understanding document does include a large section to provide context and examples."

AWK: Alex, if there is something you can find out, sooner is always better. I hear you say that the research won't be done soon.

Alex: We will do this as part of the CR process.

<jallan> +1

AWK: Were things in WCAG 2 that you also felt were subjective.

Alex: For ALT text, the outcome was the same. There was enough latitude that authors could come up with different designs. It's the testers doing something consistent to verify.

Jason: I'm just noting the note from ETS. If you're trying to find out how reliable evaluators are, you need to look in the context of content. In may very well be that there isn't enough reliability. The testing Alex referenced is importnatnt

RESOLUTION: Leave open

<jallan> close item 2

<alastairc> Examples from anyone are welcome, got some, need more.

close item 3

<laura> text spacing issues 657, 677, and 685

AWK: We have issues relating to internationalization

<Glenda> Alastair, I think that some of these things (like the bar graph David just discussed) might be best handled in sufficient techniques. What do you think?

AWK: All the comments came from Japan initially, since they don't use word spacing in Japan. Discussion asked 'are there other languages?'

<Detlev> @David: its not obvious without figures next to bars - how else map legend to graph?

AWK: But in Korean, they do use word spacing, so CJK could not be the exception.

<alastairc> Glenda - yep, I think the SC text is as solid as it can be, realiability comes down to consistent interpretation.

<laura> +q

<alastairc> I.e. understanding & techniques

AWK: One of the ideas was to limit this to Latin based langauges.
... There have also be some responses saying some Latin languages will not use the word spacing

Text spacing

Laura: I think we need to specify English or let it go, or else leave for 2.2

Alastair: The idea was to allow customization

<laura> Wayne conducted extensive text spacing research to ensure the metrics that we specified works correctly for people with low vision in the English language.

Alastair: When you plug those numbers in, you get a 28% increase in size of text.
... We're not sure where it might be damaging but we're also not sure where it helps.

<laura> I would caution against last minute tinkering at this point.

Jason: I don't pretend to understand the implications across all the languages -- and given this is world-wide, we need to get it right.

<Ryladog> +1 to Jason on timing

Jason: I'm in favour of time to understand the issues and take the time to get the proposal right. That's the perspective I'm working from.
... This is a significant SC with real benefits.

<Zakim> just, you wanted to say that what you suggested AWK, if the langauge uses these properties, it applies, if not, it can be ignored.

katie: I think it needs more time, but if these properties are not applicable it can be ignored. That makes perfect sense to me.

<Joshue108> +1 to Just KHS

James: You need to be able to increase both in languages where you can.

<david-macdonald> I can live with the exceptions for languages don't support these...

<Ryladog> +1 to James

James: If you are testing certain things, other thigns might not work.

<Zakim> steverep_, you wanted to say waiting for research on every language seems unnecessarily punitive

Steve: What AWK had put in, basically ignoring if not applicable to a language or script, seemed like a solution.

<laura> I would caution against last minute tinkering with the metrics at this point.

<Glenda> +1 to what Steve is saying.

Steve: It seems unnecessary to wait for research on every language seems off. We're talking about specific properties that affect spacing. How is it going to change after all that research?

<laura> good point steve.

<alastairc> +1 to steve, better to have something for some people.

<Joshue108> +1 to steve

Makoto: Each value should be larger for Japanese. It might be larger than the minimum value.

AWK: So if we had the exception in, you've be able to live with the language as it is?

<laura> Makoto, I used Alastair's spacing bookmarklet tool on some of your examples:

Makoto: Yes

<laura> http://www.d.umn.edu/~lcarlson/wcagwg/tests/makoto's_examples/waic.jp.png

<Zakim> Joshue, you wanted to ask about restricting it to Latin based languages

<laura> http://www.d.umn.edu/~lcarlson/wcagwg/tests/makoto's_examples/adobe.com-jp.png

<laura> http://www.d.umn.edu/~lcarlson/wcagwg/tests/makoto's_examples/kantei.go.jp.png

Josh: +1 to Steve and Alastair. We have some solid work for Latin-based languages.
... I would rather see us go ahead with the research we have rather than wait until we cover everything.
... I liked AWK's wording for exemptions

AWK: I'm inclined to agree with Steve. We could have a platoon of doctoral students doing research for years. It feels like we have data in variable levels of hardness. We are choosing a value that is lower, in order to be on the safe side.

<Ryladog> but we didn't put any real effort into internationalization - that is not good. But the exception is OK for now

<Ryladog> I can live with it

AWK: I do think we need that exception, but it can still stay there with the exception. Is anyone who feels like they can't live with the language?

<jallan> If the technologies being used allow the user agent to set text style properties, then no loss of content or functionality occurs by setting all of the following and by changing no other style property:

<jallan> Line height (line spacing) to at least 1.5 times the font size;

<jallan> Spacing underneath paragraphs to at least 2 times the font size;

<jallan> Letter spacing (tracking) to at least 0.12 times the font size;

<jallan> Word spacing to at least 0.16 times the font size.

Katie: I believe it is fine to do this. I believe we didn't put any effort into internationalization, which was a problem.

<alastairc> Exception: Languages which do not typically make use of one or more of these text style properties in written text can conform using only the properties that are typically used.

<alastairc> Which was from: https://github.com/w3c/wcag21/issues/677

<Greg> I would change it to "languages or scripts", as some languages may have different scripts using different writing conventions.

<Joshue108> +1 to exception text

Katie: And if none apply?

AWK: One or more could be all, right?

<KimD> +1 to exception without "typically"

Steve: i think we can remove the word "typically"

<Zakim> Greg, you wanted to say I would change it to "languages or scripts", as some languages may have different scripts using different writing conventions.

Greg: Very briefly, i agree with a prior comment. It should be 'languages or scripts'.

<alastairc> SuggesT: Exception: Human languages or scripts which do not make use of one or more of these text style properties in written text can conform using only the properties that are typically used.

<Joshue108> +1 to use of scripts

<Makoto> Laura, it looks fine. no probelm.

<Greg> I would change it to "languages or scripts", as some languages may have different scripts using different writing conventions.

<alastairc> Without typical - Exception: Human Languages or scripts which do not typically make use of one or more of these text style properties in written text can conform using only the properties that are used.

<alastairc> +1, added 'human' as well.

<Ryladog> Good explanation thanks

<laura> +1

RESOLUTION: Accepted as ammended with exception language

<Joshue108> Scripted languages are non-western or symbolic - rather like Devanagari, Sanskrit etc that use diactrics, signs etc

reflow

AWK: The sole issue we have is around the note.

<AWK___> http://rawgit.com/w3c/wcag21/master/guidelines/index.html#reflow

AWK: This note was causing some confusion and Makoto asked what this meant.

Alastair: Basically it is much more difficult to define the height aspect.

<AWK___> https://github.com/w3c/wcag21/issues/674

Alastair: The idea was that if content could scroll horizonally the values would be swapped, but that didn't seem absolutely fair.
... I would like to leave it as is but change "page" to "content"

Makato: I don't think 320px height is reasonable

AWK: If it was 320px in height, then the line length is going to be longer than 320.

Makoto: For users zooming to 400% there is no scrolling in 2 dimensions.
... But vertical text mode is not so popular.

AWK: So the goal would be that there wouldn't be 2 dimensional scrolling
... You want to be able to scroll left and right, or up and down, correct?

Makoto: If users scroll into 400% for horizontal, it would be okay, but for vertical users will need to scroll in 2 dimensions.

AWK: Is this a wording issue or a technical issue?

Makoto: If we require authors to... Sorry, I need to take time to find the correct wording.
... I will do my best later.

AWK: if you are viewing a screen, if you zoom in to the equivalent of 400%, you haven't changed the height or width relative to the screen. You're still zooming it, you're still seeing text.
... But you still have the same screen. What the content shows you depends on whether it is a vertical or horizontal language.
... It feels like this SC is presenting the same challenge to vertical and horizontal languages. I think it is a problem expressing it.
... We have one comment to resolve, otherwise it is okay.

Jason: What you do is clarify the note that it is applying to vertical writing modes.

AWK: Can you clarify in an email?

RESOLUTION: Leave open

pointer gestures

Steve: There were 2 issues. One, that it is the definition is unclear-- and based on discussion, I agree we need to clear up

<AWK___> https://github.com/w3c/wcag21/issues/663

<AWK___> https://github.com/w3c/wcag21/issues/634

Steve: The Understanding didn't match up Pointing gestures. The changes to the SC covers it by itself. We don't need to change the definition.

<AWK___> http://rawgit.com/w3c/wcag21/master/guidelines/index.html#pointer-gestures

Steve: The change was to add "without a path-based gesture". I don't have the text in front of me right now.

AWK: And that was for 663?

<KimD> 2.6.2: Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

Steve: It was for Mike Pluke's issue.

AWK: I'm bringing up the language

<AWK___> proposed: All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

STeve: So that effectively scopes it. So you don't need to change the definition

AWK: Say that again.

Steve: The definition is the problem.
... Single pointer used to say 'one point of contact with the screen', which I read that to me as long as you weren't using multiple fingers, it was included.

<AWK___> Proposed definition: Pointer input that operates on one screen location, including single taps and clicks, double-taps and clicks, and long presses

Steve: You can keep that defintion -- maybe make it clearer than it is now -- but you don't need to restrict it, given how this SC is written now.

<AWK___> Possible change to: Pointer input that operates with point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and single-point gestures.

Detlev: We originally needed the single pointer for Pointer Gestures.
... That's why it is talking about a single location. That causes a problem with cancellation, because you may need to move the pointer.
... My suggestion was to remove single pointer in Pointer Cancellation to avoid that mismatch.
... If we can live without "single pointer" in Pointer Cancellation, then we can hold onto the definition.
... If we take away path-based, it can be quite complicated.

Steve: Right now the two changes that were made are redundant. One or the other needs to be done.
... We can make the definition clearer, but it needs to include path-based gestures that only include a single finger.

<AWK___> Possible change to: Pointer input that operates with point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and single-point gestures.

AWK: Steve, would that address what you're saying?

Steve: YEs

Detlev: That's fine for me. My concern is that single point gestures will be understood by most as one location

AWK: Doesn't gesture mean more than one location?

<AWK___> Def: Possible change to: Pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures.

Detlev: I wouldn't take that to include path-based.

AWK: What do you think about this applying to software?

Alex: It hasn't changed.
... We're not expecting the user agent and AT to behave that way, given the exemption.
... I think we're saying it doesn't apply to software
... If the software and OS and AT you use allow you to use multi-point path based gestures, it is really hard to say 'well, for web content, it isn't allowed'

<Detlev> q

Alex: I do have to acknowledge that there is a discrepancy in logic to say OS and user agent can do it , but web content cannot.

+1 to alex

Jason: The way that distinction is drawn is shifting.

Detlev: I think the distinction is all right.
... In web you have the content, the user agent and the OS. I think it is fine to have restrictions on the web content and leave the other things alone.

RESOLUTION: Reissue CFC with updated definition

Wrapping up CFC proposals

Animation

AWK: Right now we don't have an animation in the working draft. It was suggested it be added.

<alastairc> Can't talk, on train, but if group is happy to except non motion animation, then use the latest sent to list

David: There are movement techniques that are not provocative or a major concern with people with vestibular disorders.

<AWK___> SC text: Animations triggered by user interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.

<alastairc> Which Used "motion animation". Just before Christmas Greg wanted it to include non movement

AWK: So the idea is to define animation, but make it specific to movement, rather than distraction?

David: We could just say "For non-essential movement animations..." or something like that.

<alastairc> AWK___ /David, please see latest email

AWK: We're running out of time on the call. We're quibbling about small specifics.
... Is there anyone who feels we shouldn't have this structured around motion, as opposed to colour changes

<alastairc> Check with Greg...

<Zakim> Greg, you wanted to say last I looked the Understanding was as much about distraction as vestibular, and some (not all) flashing and fading is as bad for distraction as is

<alastairc> NB: "talks about" is one instance!

Greg: The Understanding doc talks about distraction as much as vestibular disorders. So if we change this, we lose things. I would prefer to keep both.

David: We already have a requirement for a pause button.

AWK: If it starts automatically, lasts more than 5 seconds...

<laura> +1 to structuring around motion to simplify. Main issue is parallax scrolling.

Katie: I think it has to be clear what we are trying to address.

<david-macdonald> I think it needs https://www.w3.org/WAI/WCAG21/Understanding/21/animation-from-interactions.html

David: Could someone point out the understanding doc that would have to be removed if it was restricted to movement

<alastairc> I wrote it, can say that it only had one mention of distraction.

<alastairc> AWK___: there is an email to the list, to get consensus, we can CFC that.

Katie: What are we going to do about international reviews?

Michael: We sought out internationalization guidance in october

Katie: I'm really concerned about other languages in all our other SCs.

AWK: Michael, Josh and I will talk and see what our options are. If people have other ways of getting feedback, please feel empowered to enable them.

<alastairc> Katie : I did try, a lot, for reflow. It wasn't until I cornered Richard at tpac that I got anywhere!

<Ryladog> thanks Alistair!

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. leave open 1.3.4
  2. leave open Target size.
  3. Leave open
  4. Accepted as ammended with exception language
  5. Leave open
  6. Reissue CFC with updated definition
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/01/16 18:10:06 $

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/Objectivity/Subjectivity/
Succeeded: s/from EPS/from ETS/
Succeeded: s/japanase/Japanese/
Succeeded: s/excpetion/exception/
Succeeded: s/issue with have/issue we have/
Default Present: AWK, KimD, JakeAbma, kirkwood, JimA, Kathy, bruce_bailey, MichaelC_, alastairc, MichaelC, Joshue108, Rachael, Greg_Lowney, alex, marcjohlic, SteveRepsher, Laura, jasonjgw, shadi, Judy, Mike_Elledge, Glenda, MikeGower, chriscm, Makoto, Katie_Haritos-Shea

WARNING: Replacing previous Present list. (Old list: AWK, Laura, MichaelC, jallan, JF, SteveRepsher, KimD, jasonjgw, MikeGower, shadi, Aex, Detlev, Rachael, Mike_Pluke, Greg_Lowney, david-macdonald, JakeAbma)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK, KimD, JakeAbma

Present: AWK Detlev JakeAbma JimA Kathy KimD MichaelC alastairc bruce_bailey kirkwood Joshue108 Rachael Greg_Lowney alex marcjohlic SteveRepsher Laura jasonjgw shadi Judy Mike_Elledge Glenda MikeGower chriscm Makoto Katie_Haritos-Shea
Found Scribe: jallan
Inferring ScribeNick: jallan
Found Scribe: gowerm
Inferring ScribeNick: gowerm
Scribes: jallan, gowerm
ScribeNicks: jallan, gowerm
Found Date: 16 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.)


[End of scribe.perl diagnostic output]