<alastairc> scribe:alastairc

<scribe> scribe: alastairc

Device Sensors https://www.w3.org/2002/09/wbs/35422/resolving_device_sensors/results

Heads up on survey for purpose of controls

AWK: Survey for additional thoughts & comments on that, after this call. It will be fairly lengthy, but you don't have to make lengthy comments on it unless you have long comments.

Status

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_countdown

AWK: This page is where we are at with 2.1 SCs. On the second half we have cleared comments, with 8 SCs right now. At the top, adapting text is in CFC now, but we have a bunch more.
... plenty of A & AA ones where we haven't cleared comments or come to consensus on them.
... be aware we have a bunch, and the end of the week is our deadline. We need to keep at it, and keep focused. I'm keeping the page updated so you can take a look.

Change of Content https://www.w3.org/WAI/GL/wiki/Comment_Summary_3-2-7

AWK: We talked about this yesterday, did not come to resolution yet. A couple of issues raised, still need to cover a bit more. E.g. how frequent the updates would be, and whether it decreases the user-experience until the tools can do the right things.
... the link in the agenda item shows the current text, updated text, and comment numbers.

Update SC text:

For content which does not take focus and which dynamically updates as a result of user action or application status changes, the following are true:

- Changes in content are programmatically determinable through role or attributes;

- Notification of changes to content is available to user agents, including assistive technologies.

AWK: What do people think, are we close?

<Zakim> steverep, you wanted to say we need to get rid of "user action"

Steverep: Need to get rid of user-action, perhaps MichaelG can talk about that? Result of user-action is largely covered by 4.2.1, so this gets us back to every user-action needing something.

mgower: I could take this offline and update for tomorrow?
... the user-action bit, most user-actions don't meet the criteria here. Where I do something that creates a change...
... I think Steverep is right, we can cover it with status changes and remove the user-action bit.
... I'll take that offline.

AWK: Do we need to define application status changed?

mgower: We pulled the definition and put it in the language, but it has changed since. If we take the note and turn into a definition that should work.

<Zakim> AWK, you wanted to say that I remembered that we also discussed "For content which does not take focus and which dynamically updates as a result of user action or application

<AWK> "For content which does not take focus and which dynamically updates as a result of user action or application status changes, notification of changes to content can be programmatically determined by user agents, including assistive technologies."

AWK: Yesterday I mentioned a combination of the two bullets (above).

<AndroUser2> Yep that works

AWK: that was another option.
... Shall we word-smith this, or get a general sense of direction and approval tomorrow?

<Zakim> Greg, you wanted to say that "can be programmatically determined" is not as good as notification

Greg: on 'can be programmatically determined', which might be duplicating something we have? In theory it could be on a loop in the content looking for change. AT in the past has shown it is not nearly as efficient at getting a notification.
... I'd lean towards something that makes the content generate notifications, rather than poll for changes.

AWK: We do use the 'can be prog det', that doesn't preclude it happening via a notification message, but the notification is resulting in a...

Greg: that is a super-set of the method of notifications, but if the idea is to let the AT know something happened in a timely fashion, then having the AT build that off-screen model doesn't really work in many cases. Also
... what about the fact that the user can already get at those content updates on screen via AT?

AWK: So you're saying the whole page is prog-det, so an AT could do continuous diffs, so they could already determine the changes.
... That is not the intent!

Greg: The word notification is important to get more than that.

AC: Don't think we need the final bits on UAs and ATs.

AWK: I'd be happy to trim that

<AWK> "For content which does not take focus and which dynamically updates as a result of user action or application status changes, notification of changes to content can be programmatically determined by user agents."

Greg: I felt the 1st bullet was biasing me against it.

Steverep: Ultimately I'm happy to iterate and come back tomorrow. I also don't think we need the UA/AT bit. I'm a little uncomfortable with it talking about the not taking focus, as progress bars do tend to take focus, so would rather take that bit out.

<Alex_> don't know any other

Steverep: question to help craft language: Is there a way, other than ARIA, to make this happen? Should it be scoped to markup languages?
... I don't know what other web technologies could do it, other than firing the events in the accessibility APIs?

jamesn: The most common way is to move focus to content.

AWK: So the way a tech (without ARIA) would meet it is by moving focus? As appropriate.

JamesN: That's how many ARIA apps do it anyway.

Steverep: That's a dangerous technique to rely on.

JF: May not be prefered, but a viable technique. I don't think it requires ARIA, there are other techniques so I wouldn't want it to scope just to markup.

<steverep> +1 to Mike - this is meant to cover things where moving focus is not appropriate

mgower: Where you put the focus on the new info, that is scoped out. Where you can't / don't want to do that is specifically the scenario we want to cover here. The thing has no role, there's no reason for a user to know about it unless they stumble across it.

JamesN: It doesn't seem to cover both cases now?
... don't want to be a case where you pass 4.1.2 but don't pass this.

mgower: If something can take focus, should be covered by 4.1.2

(not sure I've got all this, please edit if you understood it all!)

jamesn: If you have a search screen and do a search, you move the focus to the top of the search screen.

mgower: you'd have interactive things in there, can't move focus to something that doesn't take focus .

jamesn: It is a common pattern to do so, helps screenreader users, may confuse keyboard users.

<JF> +1 to James there

jamesn: you wouldn't do it in all scenarios, I just want to make sure we can use the best technique in that scenario.
... can't read right now, in a car!

AWK: Is the single line version ok?

"For content which does not take focus and which dynamically updates as a result of user action or application status changes, notification of changes to content can be programmatically determined by user agents, including assistive technologies."

<Zakim> AWK, you wanted to ask if "have focus" is better

AC: Oops, I included the last bit on AT.

<Joshue108> Text sounds good

AWK: Some of the things we are talking about might be focusable, but not focused.

<Joshue108> +1to have focus

Jamesn: problem is that you might move to the first thing that does take focus, but the rest of the table has updated and that isn't notified.

<JF> I agree - think about sortable table columns

AWK: Worried it might be interpreted in a way that means, if you go to the first of 20 items that have changed, then people might say you have to provide notifications of all the others.

<Zakim> steverep, you wanted to offer a simple shopping example where moving focus would result in less accessibility

steverep: Getting into an area due to trying to scope it down in the first place. If this is scoped to changes of content where moving focus becomes a viable technique, then we've scoped too wide. This isn't mean to cover every possible change of content.
... previously had been scoped to a couple of roles not covered by 4.1.2. Whether it's communicated by the label on the button, or expanding a tree item, you don't have to put focus on what's opened, but it is comminicated by putting the right states on the component.
... want to scope to things not covered by ARIA live regions, like success messages where you put role of status/message on, things which are not suitable for moving focus to.

Joshue108: I was on queue to agree with James about SPAs, distinction between some content has changed, and what you need to move focus to. I like what Steve was saying. As long as we're aware of that, sounds good.

<Greg> hanges...

<Greg> ...to content is available to user agents”, or 4.1.2’s wording “notification of changes to these items is available to user agents”.

AWK: Sounds like Steve and Mike should work on a bit further, add to agenda for (near) future call.

Greg: (comment above)

AWK: In order to show conformance claim, you'll have to show user-agent support. You can't issue notifications into the ether, but show they can be used.
... Let's let Mike and Steve think about that, re-raise tomorrow/thursday.

RESOLUTION: Leave open for more work

<Zakim> Greg, you wanted to say I’m still worried that “notification of changes to content can be programmatically determined by user agents” may not require notifications, only that

Target Size (AA) https://www.w3.org/2002/09/wbs/35422/resolving_target_size/results

AWK: Didn't come to a resolution on this, see if we can get somewhere. Survey has the new version, just looking for the new(er) verison.

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets

AWK: The new one is under 'alternative wording'.

Kathy: There were some updates on the mailing list, I'll paste in
... Mike suggested taking out the text bullet altogether.

AWK: So text links would need to be 44x22?

Kathy: We'd add to the understanding that suppressing the UA styling would make the SC applicable. So, we wouldn't do this just for text-links, all controls. If you dont style it you're exempt, but if you do you need to meet it.

<Zakim> gowerm, you wanted to explain text exemption

gowerm: this is maybe a bit of acrobatics, but we already have a line on user agent control. If the author hasn't modified a text link this doesn't apply. If we include links under user-agent control.
... the exception that might be in understanding, is where the author only altered the colour style of the link. Removing underline, suppressing focus indicator, then would apply.

JamesN: I don't see how we could come up with a list for that.

AWK: Probably not many links that are not controlled to some degree, bold, font-family, etc.

gowerm: To me it was an easy way to scope it, but if people don't think it would fly, ok.

<steverep> We would need to look at every CSS property to investigate how user agents adjust target size in response

<gowerm> Steve, only to the degree that styling is used to change links in a way other than other text.

Kathy: the other thing that may help with some of the concerns, instead of bullets for text links, change it to be targets in a block of text.
... exception for targets in blocks of text.

AWK: one of the comments made, was that if we don't have links in the text covered then we aren't helping people.

Kathy: I'd like to see that at AAA, I could live with it not being in there at AA.

<Kathy> Block of Text: The target is in a block of text;

<Kathy> Remove this bullet: Text Links - The target is a text link with a size that is at least 22 pixels in width or height unless it is in a block of text;

AWK: Any other concerns?

<Ryladog> I like it

NB: https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets#SC_revision_discussed_on_Nov_21_call_.28Kathy.27s_suggestion.29 with the above ammendment.

<JakeAbma> ?me I have a bad connection but added some text in the questionnaire

<Zakim> steverep, you wanted to ask if a table is a block of text?

Kathy: Definition of block of text from WCAG.

Steverep: so every table cell needs to be at least 44x22px, if it is a link, or the content of the cell are a link.

AWK: If the content of the cell is a button or an image that is linked, then yes, would need to be 44x22. If you have a table cell with one word, then it would be covered (for that text).

<Kathy> Text Links - The target is a text link with a size that is at least 22 pixels in width or height

Kathy: Could leave in text links exception instead.

JamesN: Then you page navigation wouldn't meet it either, which we want to cover.

<Zakim> gowerm, you wanted to say what about including tabular content in blocks of text?

gowerm: Can we update 'blocks of text' to include tabular content?
... Maybe people wouldn't consider tabular content to be blocks of text?

<steverep> ... within a block of text or data table

Mike_Elledge: For mobile apple suggests 44x44, android is 48x48, thought I'd just raise that.

Um, that's where the whole thing started, then we had to reduce!

Mike_Elledge: If that's the industry standard, should we aim for that?

AWK: Apple/Android don't include text links in their guidelines.

<steverep> Agree 22 is very arbitrary

JakeAbma: Updated my comment to questionnaire, had questions about 44x22, what is the rationale for the 22px? Struggle with that, as one sentence can be bigger than 2 sentences, have same problems. Other aspect, if you have a font size of 17px you're on the good side, but every size lower than that, I see sites with 12, 14, 16px text.
... in other cases those sizes / words are not possible. For content authors on CMS, hard to know if they are on the right side of the sizing, do they need to use more words to meet it?
... I didn't get an answer, concerns still there.
... What's the rational, just take half? IMO not a well founded reason.

AWK: meeting 44 / 48 was too difficult.

<scribe> scribe: JF

<scribe> scribe: JF

AWK still legitimate uses for very short links (ex: endnotes, footnotes, etc.)

which is why it went to 22 in either diminesion

AWK: numbers have changed over time, and we need to be careful about scoping

but we still need to ensure that the ratios make sense

<Zakim> gowerm, you wanted to say I have a real world question about this one

<gowerm> http://wafflerama.com/a11y/keyboard.shtml

but for links in a menu or an outside bar, it is easy to add additional padding, but in blocks of text its harder

MG: if you open that page in a browser window, it renders fine on a mobile device

yet it will not be able to meet this SC as presented

it's not an authoring issue, but a User AGent issue

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

so... still trying to understand how to square-up native default settings issue

JOC: Appreciate that there is some back and forth, but value in piggy-backing on industry standards, so in favor of that

but with some noted exceptions

(like footnotes, endnotes, etc.)

AWK: seems there is broad agreement in the value of a SC like this (aka larger targets)

Q: How much of what we have today is related to what we already have (had)?

KW: this transcends just mobile, and instead on touch interface

investigated a lot of studies and resources

related to touch size and success, different finger sizes, etc.

when investigating relationship sizing got to CSS pixel sizes

KW: then we looked at menus and similar constructs, which is how/when we got to the "other means" exception
... early on we also suggested that any impact created by the user-agent also falls under an exception, as author is not modifying in any way
... so much of what we have today is about not over-riding reflow and pinch-zoom (etc.)

AWK: is there a portion of this taht we can all agre on that will have a net benefit for all users?

but feels like right now we have some core issues - anyone feel otherwise?

KW: even with the new language that exclues all links in blocks of text?

AWK: notes that it would still mandate all table cells to a minimum of 44 X 22

<Lisa> i am happy with current wording

KW: dont table cells have additional padding already?

<Lisa> would rather it stays in

<Glenda> I think we need to cowboy up and reach some consensus here. If we talk to this to death, we are going to miss this entirely for WCAG 2.1.

<Lisa> +1 to stay in

SR: with data tables, but suspect that large data tables... tables with lots of content, it may be too much, may introduce additional horiz. scrolling
... this was similar to menus as well (and agrees with Jake, 22 px seems very arbitrary)
... agree that in many cases, you can make these changes, but often layout considerations will also introduce a conflict

<Ryladog> I would

AWK: in the case of the data table, could not the exception for layout needs apply here?

<Ryladog> clarify in Undertanding

JA: biggest concern is block of text - want to be sure we don't miss this

still not sure why the exception is still there

KW: if we have just one sentence - to a certain extent we are trying to meet user needs. If you only have one sentence you are looking at

I don't thin it is a huge burden to adjust the link size, even if only in one sentence

we need to balance feasible against needs of users

GS: wondering if a compromise is available - don't look at text links, but just other types of targets

KW: the menu issue is huge

<Kathy> Inline - The target is in a sentence;

GS: remain concerned that if we don't get something we'll really be missing out

KW: I agree, which is why there is lots of flexibility here

<Ryladog> lets do that

<JakeAbma> having problems with the difference between one or more sentences. So the exception: * Inline - The target is in a block of text; is about two sentences. So one sentence always needs 44x44 CSS pixels. Better to except to sentences or inline text instead of blocks of text

trying to get this right

<Joshue108> +1 to Glenda

GS: hoping we can find a compromise position now, so that we can advance forward

<Zakim> gowerm, you wanted to say so does any page that fully displays in a mobile browser (so that its text is tiny) immediately fail this?

MG: to return to my concern - in a situation where a page fully displays with a small font, does this instantly fail?

KW: we're not taling about actual physical size, we

<Glenda> +1 css pixels

're talkng about CSS pixels, which changes with device

KHS: How about we move the pieces we're taking out, and move them to AAA?

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets#Alternative_Wording

AWK: need to get the AA figured out first

<kirkwood> +1 to Glanda’s suggestion, suggestion to make exception for inline text link

KW: we're doing that already

<gowerm> gowerm: Kathy?

<Kathy> yes

<Kathy> it falls under user agent control exception

<kirkwood> +1

<Ryladog> +1

<JakeAbma> +1

<Glenda> +1 (love it)

<Kathy> +1

<marcjohlic> +1

<jallan> +1

AWK soliciting opinions on compromise

<Makoto> +1

<Mike_Pluke> +1

+1 from me

<laura> +1 Need a definition for sentence

<Brooks> +1

<steverep> Still think 22 has no real rationale, and prefer to use block of text despite its definition (is MathML a sentence? is a bulleted list under a paragraph?)

<jallan> so its styling for links, buttons, input controls, etc.

<Glenda> We do NOT need a definition for sentence.

MG: so the moment I make any styling changes, then I potentially can fail as the UA is no longer offering native CSS

KW: it is constrained to the specific control

<Kathy> ok

<Ryladog> No definition for sentence

<gowerm> -1 I understanding what's being desired here, but i think it's a Pandora's box

<laura> okay. let’s not define sentence.

AWK: don't need defintion for sentence

MG: sounds like the author is responsible for user-agent behavior when they start to add styling
... sounds like we're imposing RWD to succeed her

GS: is it true that the only time Mike's concern would surface is if/when they style the control down to a very tiny size

KW: the target size is not set by the UA

GS: so the only time Mike's concern surfaces is when you have specifically set sizing

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

KW: we can change the last bullet - the *size* is determined by the user-agent, not the appearance

<Glenda> +1 to “size”

<JakeAbma> +1 to size

[some mummers of agreement]

<marcjohlic> +1 to that new wording

MG: if that is in the Understanding doc, then that's fine

<Ryladog> I like it

<Ryladog> +1

+1 to new language

<gowerm> +1 I like that much better

<alastairc> Size is good, rather than style.

<marcjohlic> +1

<Kathy> +1

AWK: are we happy with this now?

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets#Alternative_Wording

<gowerm> +1

<Kathy> Inline - The target is in a sentence;

KD: have we addressed really tiny links (like single character links, etc.)?

<Alex_> are we saying a math equation is a sentance?

KD: so if we have a text link, a symbol, another text link... all on one line...

KW: that is all now excluded from the AA requirement

KD: do we need a specific definition?

<gowerm> MathML

<Ryladog> Yes, in Understanding Kim

<steverep> In other words, we take a very loose interpretation of "sentence"?

<JakeAbma> if we don't already have a proper answer we need a definition for sentence

KD: [explains end-note links]

KW: yes, this has all been excluded. We can elaborate in Understanding

AWK: we could say something like the target is in a sentence of (similar) block of texgt

<Glenda> Yes. put it in Understanding.

<Ryladog> Yes, put in Understanding

<Zakim> steverep, you wanted to say I'd prefer using block of text

AWK [expressing concern about defining 'sentence' / 'block of text

SR: feel that 'sentence' is a tad too prescriptive - prefer block of text

<Ryladog> yes

<Alex_> hard to justify math is essential

<Glenda> block of characters

AWK and SR: discussing wether MathML is in scope

<gowerm> just add "equation" in block of text definition

SR: I interpret mathematical content as "text"
... don'twant to add math in one SC (when in fact it should be in multiple SCs)

<steverep> Then +1 to sentence or block of text

AWK: sounds like we need to address some of these issues in Understanding

<jallan> do math in Understanding

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets#Alternative_Wording

but it also sounds like we have consensus around the draft language now

AWK: reads out revised text - asks for consensus

<Glenda> +1 to sentence or block of text.

<KimD> +1 - I like it

<kirkwood> +1

<Lisa> +1

+1 to sentence or block of text.

<Makoto> +1

<JakeAbma> 0 why make the cognitive load to understand bigger

<JakeAbma> +1 to Alex

<Kathy> Inline - The target is in is one or more sentences;

<KimD> +1 to AWK's comment - Yes, exactly

<Glenda> live with it :)

<steverep> Then +1 to sentence or block of text (concede even though I'm not sure how we plan to rationalize 22px)

<Kathy> I prefer my change

<AWK> Level AA The size of the target for pointer inputs is at least 44 by 22 CSS pixels except when:

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

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

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

<JakeAbma> Also like Kathy's more

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

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

<Ryladog> Yes, in Understanding

<AWK> Level AA The size of the target for pointer inputs is at least 44 by 22 CSS pixels except when: Essential - A presentation of target is essential to the information being conveyed; Equivalent - 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

<AWK> (that one)

<JakeAbma> +1 to Kathy

<alastairc> I think that would be: https://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_2.1/targets&oldid=8767#Alternative_Wording

KW: can we just say... without having people asking what is the difference, can we just say it is in a [???]

KHS: people are familiar with block of test in WCAG, not confusing

+1

<laura> +1

<JakeAbma> +1

<Ryladog> +1

<alastairc> +1 (happy to move on)

<Makoto> +1

<Glenda> +1

<Mike_Pluke> +1

<marcjohlic> +1

<Lisa> +1

RESOLUTION: Accepted as amended at https://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_2.1/targets&oldid=8767#Alternative_Wording

<KimD> +1 (with the additional understanding stuff.)

<KimD> *YAY!

<AWK> Need to get into Understanding: User agent control, math, footnotes, examples of essential, links in tables

KW: we need to be sure we've covered all of the concerns about he various specific link types

<Brooks> +1

<Ryladog> +1

+1

RESOLUTION: Open issue for implementation follow up

<JakeAbma> +1

<Mike_Pluke> +1

<Ryladog> yes

<Kathy> yes

AWK: take a break for 10 minutes, return at top of hour

<AWK> Call resumes in 3 minutes

<jallan> scribe: allanj

<AWK> Call resumes in 1 minute

accepting comment responses for Target size

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets#Comment_responses

<jallan> awk: have responses for all comments

<jallan> ... on the page above

<jallan> ... just updated for current wording agreed to today.

<Kathy> +1

<jallan> awk: any concerns or can we approve

<jallan> <<crickets>>

+1 to accepting as proposed

<Glenda> no objections

RESOLUTION: Accept responses to comments for Target Size at https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets#Comment_responses as proposed

<JakeAbma> +1

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets#Alternative_Wording

AAA Target size

<jallan> awk: remove 3rd bullet. Text Links - Text Links - The target is a text link with a size that is at least 22 pixels in width or height;

<Glenda> would we want to increase the size to match mobile guidelines?

<jallan> kw: this was added because of discussion at TPAC. folks thought there should be a minimum height

<jallan> ... prefer to remove it totally

<jallan> awk: so mobile size is 44x44

<jallan> Level AAA The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:

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

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

<jallan> Text Links - The target is a text link with a size that is at least 22 pixels in width or height;

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

<jallan> mg: because of equivalent link must keep 22x44

<jallan> kw: need block of text in 3rd bullet

<jallan> Level AAA The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:

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

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

<jallan> Text Links - The target is a text link with in a sentence or block of text with a size that is at least 22 pixels in width or height;

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

<jallan> Level AAA The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:Essential - A presentation of target is essential to the information being conveyed;Equivalent - The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;Text Links - The target is a text link with in a sentence or block of text with a...

<jallan> ...size that is at least 22 pixels in width or height;User Agent Control - The size of the target is determined by the user agent and is not modified by the author

<Kathy> Inline - The target is in a sentence or block of text with a size that is at least 22 pixels in width or height;

<jallan> sr: where does 22 come from. what do we say in understanding?

<JakeAbma> +1 to Steve, also my qyestion

<jallan> kw: research on wiki.

<Joshue108> Thanks Michael, I'm driving

<jallan> gs: on bullet3, a footnote of 1, then it must be height or width must be 22

<jallan> kw: yes

<Zakim> gowerm, you wanted to say I think it needs to be reworded: The target is a text link at least 22 pixels in width or height in a sentence or block of text;

<jallan> jake: for bullet3 if we have 17px font, then a single character should be 22x22 to be sure to have a good target size

<jallan> kw: restrict to text links only

<KimD> +1 - I thought the same

<Kathy> Inline - The target is 22 CSS pixels in width or height in a sentence or block of text.

<jallan> mc: sounds like a decistion.

<gowerm> Inline - The target is at least 22 CSS pixels in width or height in a sentence or block of text.

<gowerm> scribe: gowerm

Michael: So you would be adding the word about spacing to the inline one?

AWK: The triple A one has 4 bullets.

<KimD> *it's here, Michael: https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets#Alternative_Wording

Kathy: "with a spacing of at least one pixel in a block of text" is what I was submitting
... Based on research, we found a need for spacing around the target
... Spacing between the targets.

AWK: That feels like something we haven't discussed much. I'm wary of drafting on the spot.
... Can we try to grab the language, and do this short review Wednesday or Thursday?

<jallan> scribe: jallan

<gowerm> Inline - The target is 22 CSS pixels in width or height in a sentence or block of text.

<Kathy> Inline - The target is at least 22 CSS pixels in width or height in a sentence or block of text.

awk: updated wiki

<gowerm> +1

awk: polling group without spacing language. any objections to current AAA in wiki?

<JakeAbma> -1 to Text Links - The target is at least 22 CSS pixels in width or height in a sentence or block of text; because the clickable area can still be very small and thus not very user friendly

<JakeAbma> prefer something like 22x22

<Kathy> Text Links - The target is at least 22 CSS pixels in width and height in a sentence or block of text;

<Kathy> Inline - The target is at least 22 CSS pixels in width and height in a sentence or block of text;

<Glenda> I like Jake’s suggestion…at AAA

<KimD> I can live with that at AAA

<JakeAbma> +1 for the new text!

Inline - The target is at least 22 x22 CSS pixels in a sentence or block of text;

awk: why change wording from text links to inline.
... want to add spacing or go as is.

<AWK> Current: Level AAA The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when: Essential - A presentation of target is essential to the information being conveyed; Equivalent - The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels; Inline - The target is at least 22 by 22 CSS pixels when in a sentence or block of text; User Agent Control - The size of the target is determined b

kw: if we have consensus... just leave it

<AWK> Any objection to accepting as amended?

awk: any objections?

<Glenda> +1 to accepting as amended

RESOLUTION: Accept AAA as amended

open item 4

close item 6

<AWK> Steve's update:https://github.com/w3c/wcag21/issues/380#issuecomment-347565668

<steverep> See https://github.com/w3c/wcag21/issues/380#issuecomment-347565668

sr: clarifies how to apply this, and what is and is not an 'activation'

For functionality which can be operated using a single pointer, at least one of the following is true:

No Down-Event: The down-event of the pointer is not used to execute any part of the function;

Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or undo the function after completion;

Essential Completing the function on the down-event is essential.

awk: drag/drop the down even is important, initiates the drag. would not meet the first bullet, but meet bullet2.
... how abort/undo drag and drop

sr: control-z to undo, or 2 stage (dialog - are you sure)

awk: also, change def of single pointer activation to just single pointer

sr: activation is functionality. it is the pointer we are concerned with ... 1 point on screen. didn't suggest any wording

awk: we also use single pointer activation in another SC

sr: looked it up. it is editorial. change the article, remove 'activation' all should be good

awk: what do people think?

For functionality which can be operated using a single pointer, at least one of the following is true:

No Down-Event: The down-event of the pointer is not used to execute any part of the function;

Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or undo the function after completion;

Essential Completing the function on the down-event is essential.

awk: any concerns? KW is this ok?

kw: reviewing original

<steverep> Proposed:

<steverep> For functionality which can be operated using a single pointer, at least one of the following is true: •No Down-Event: The down-event of the pointer is not used to execute any part of the function; •Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or undo the function after completion; •Essential Completing the function on the down-event is essential.

awk: are we missing anything by eliminating platform generic activiation

kw: ok with removing platform wording

<Zakim> gowerm, you wanted to say it looks like we're missing a basic up event

mg: rely on user agent or put in content in the first place
... seems we lost the basic ... its ok to use an up event.
... so must have an undo.

sr: not so, the down event does nothing. when you release the button, it is undone and nothing happened.

<Alex_> not unique to vo

mg: if using voiceover, I can press a letter on keyboard and hear it. this may be a screen reader issue
... not a single point interaction and give feedback to know what they will do. don't want to invalidate information seaking
... in edit field. want to move cursor. some platforms enlarge the area on the down even.

awk: there are thinks that happen on down, but completion is on up event.

<Alex_> this is the same in context menu

kw: need to detail this in Understandign

brooks: what will up event do to delay on interactions with the screen. Impact on interface responsiveness

kw: most things are done with up events, except piano - down is essential.

<Zakim> Greg, you wanted to say What about exempting actions where button-down triggers a purely transient effect, e.g. a pop-up that appears on button-down and disappears on button-up.

kw: where down is essential for timing, it falls under bullet3

<Greg> What about exempting actions where button-down triggers a purely transient effect, e.g. a pop-up that appears on button-down and disappears on button-up. That is, in effect, providing a built-in Undo. Also re Andrew's point, I think the term "completion" is ambiguous, and this would take care of it.

gl: what about exempting transient down events. popup menu
... webapp - see a graph, as you move pointer to define a region, provides info on the region on up event.

kw: and can dismiss the region info

awk: proposed wording to remove completion?

<Greg> So something like: •No Down-Event: The down-event of the pointer is not used to trigger any events that are not purely transient.

<Greg> Or "... effects that last beyond the up-event."

awk: so 'completion' is ambiguous

gl: yes

awk: popup handled by bullet2 - up event

<Kathy> No Down-Event: The down-event of the pointer is not used to execute the function;

awk: moving finger between options, abort by moving finger off screen, or some other undo

gl: not follow

<Kathy> No Down-Event: The down-event of the pointer is not used to execute the completion of the function;

gl: point and mouse down to see popup definition. def goes away when mouse up. the action is the showing of the informaion - down event.
... perhaps up is abort.

awk: usually see described behaviour with hover

<Zakim> steverep, you wanted to try to address "completion" - we could also say "outcome" but that's just as ambiguous

gl: webapp

sr: def of functionality, process or outcomes... what is outcome. could change completion to outcome, but doesn't mean anything.
... if I click down to popup info it fails 2.1.

<Greg> I did not say this was the *only* method of getting the definition; this SC does not have (nor is it intended to have) an exemption for alternative methods.

sr: think its covered.

gl: this SC doesnot have an alternative method exemption, because it is about accidental activation.

<AWK> "* No Down-Event: The down-event of the pointer is not used to execute any part of the function;"

<AWK> suggests

<AWK> * No Down-Event: The down-event of the pointer is not used to execute the completion of the function;

kw: don't want completion on the down event
... why "part of the function"

sr: what is the outcome. drag/drop final action is the drop. the user method on b1 - while button is down, user can move away and nothing happens

kw: scenario. down magnifies so you can see where you are working.

awk: overridden by bullet 2
... have GL concern. tho some think it is already resolved.

<Greg> Could replace "any part of the function" with "any non-transient effect" or some such.

awk: app where down event is important, but up event is the cancel action

<AWK> * No Down-Event: The down-event of the pointer is not used to execute any part of the function, or only triggers a transient event;

gl: down event triggers transient event. don't think SC was intending to cover this kind of interaction
... or transient effect

<AWK> * No Down-Event: The down-event of the pointer is not used to execute any part of the function, or only triggers a transient effect;

awk: like effect

sr: need to think more. live with it for now. need to define 'transient event'

<JF> agreed - definition of transient effect is vague (non-existant?)

gl: transient- def: something that does not last after up event

<AWK> * No Down-Event: The down-event of the pointer is not used to execute any part of the function;

<AWK> * Transient: down-event only triggers an effect that is removed on the up-event

<Greg> How about simply: "No Down-Event: The down-event of the pointer does not trigger effects that last past the up-event"?

awk: does this cause other problems

<Kathy> I need to leave for another call

RESOLUTION: leave open

rrsagent: make 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/loke/like/
Succeeded: s/+!/+1/
Succeeded: s/ae/are/
Succeeded: s/don';t /SR: don't/
Succeeded: s/=1/+1/
Succeeded: s/in  in/in/
Succeeded: s/Accespt/Accept/
Succeeded: s/transient something/transient- def: something/

WARNING: Replacing previous Present list. (Old list: AWK, Detlev, Joshue108, MikeGower, marcjohlic, SteveRepsher, Glenda, Bruce_Bailey, KimD, Brooks, kirkwood, Rachael, Katie_Haritos-Shea, Laura, Alex_Li, jasonjgw)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK

Present: AWK JakeAbma JF MichaelC Alex_ alastairc SteveRepsher kirkwood Makoto mikegower Laura Mike_Pluke Kathy Mike_Elledge Greg_Lowney Brooks marcjohlic Glenda Jan Katie_Haritos-Shea
Found Scribe: alastairc
Inferring ScribeNick: alastairc
Found Scribe: alastairc
Inferring ScribeNick: alastairc
Found Scribe: JF
Inferring ScribeNick: JF
Found Scribe: JF
Inferring ScribeNick: JF
Found Scribe: allanj
Found Scribe: gowerm
Inferring ScribeNick: gowerm
Found Scribe: jallan
Inferring ScribeNick: jallan
Scribes: alastairc, JF, allanj, gowerm, jallan
ScribeNicks: alastairc, JF, gowerm, jallan
Found Date: 28 Nov 2017
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.)