W3C

- DRAFT -

SV_MEETING_TITLE

30 Nov 2017

Attendees

Present
MikeGower, JF, Joshue108, alex, MichaelC, Rachael, Bruce_Bailey, Greg_Lowney, Makoto, Brooks, AWK, marcjohlic, Laura, Katie_Haritos-Shea, Kathy, SteveRepsher, alastairc, Lisa
Regrets
David
Chair
AWK
Scribe
gowerm, Kathy, jallan

Contents


<gowerm> scribe: gowerm

change of content (https://github.com/w3c/wcag21/pull/594)

<MichaelC> 90 km / hr is below highway speed

<AWK__> +AWK

<Rachael> Mike: We constrained the SC to get clear agreement. Its a subset of the original change of content focusing only on status messages.

<Rachael> The description of status messages is a glossary term to keep it contained. We have changed language to address concerns from the last time we talked.

<Rachael> status messages are programatically determed through role or attributes (properties?) so they can be presented to users or assistive technology without receiving focus.

Status messages are programmatically determined through role or attributes such that they can be presented to the user by assistive technologies without receiving focus.

Changes in content that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process, the existence of errors, notification of change in content or similar notifications.

<Rachael> status message definition above.

<Rachael> I think we said "roles or propeties" not "roles or attributes"

<Rachael> Also notifications of content was removed from the definitions.

<Rachael> Lisa: What if you want the status message to have a change in focus. As written this looks like it requires a change in focus.

<Rachael> gowerm: We can add a change to the defintion to make that explicit if folks are concerned about that. Do people share concern that as written this prevents people from moving focus?

<Rachael> AWK: Lisa, would you want to move the focus?

<Rachael> Lisa: Yes, if I get a warning , I may want it as a modal where the focus lands on it and then I hit the OK button. Sometimes I want to move the focus.

Changes in content that are not changes in context

<Rachael> gowerm: Change the defintion "changes in content that are not changes in context" because there is a definition of changes in context.

<Rachael> So status messages would be come messages that do not get focus.

<Greg> ...latter is confused with the content being programmatically generated.

<Rachael> A message that does not change context is what we are addressing.

<AWK__> http://rawgit.com/w3c/wcag21/status-changes/guidelines/index.html#status-changes

<Rachael> AWK: Current language does not preclude assistive technology providing focus. Link above is rawgit version.

<Rachael> Greg: Slight rewording was fixed. I am concerned about the so that clause.

<Rachael> We always avoided saying why you do something because it implied a whole lot going on beyond scope of content author. This would be the only SC that includes a So that.

<Rachael> includes an explanatory clause. It introduces risk.

<Rachael> Greg: It may not be a blocking issue. We were just careful in other standards to avoid doing that.

<Rachael> Steve(?): I am OK removing it but it was meant to imply that you had to do it to define a role.

<Rachael> AWK: I think it is the presented to a user part that is the issue.

<Rachael> Greg: It is the such that clause. It also includes the same issue I pointed out in email.

<Rachael> AWK: What should it say?

<Rachael> Greg: We would cut out everythign after such that.

<AWK__> https://www.w3.org/2017/08/telecon-info_ag2

<Rachael> gowerm: The author could set it up to meet this SC but not allow the AT to access the information.

<AWK__> Status messages which do not receive focus can be programmatically determined through role or properties.

<Rachael> Assign role of status and aria-live off and it won't communicate it to AT. There is no other AC that requires making the information available to AT.

<Rachael> AWK: Status messages which do not receive focus can be programmatically determined through role or properties.

<Zakim> Greg, you wanted to say in the past we explicitly avoided "so that" clauses as it implies other, unrelated things AT wants to do (present content without focus changing) beyond the

<Rachael> gowerm: James had concerns about the "Which do not receive focus" which is why we wrote the defintion the way we did

<Zakim> Bruce_Bailey, you wanted to ask if "or similar notifications" makes pass/fail hard to test

<Rachael> If you don't include the requirement about not moving focus, anyone can makethe argument that the user can move the focus to the text and meet this SC.

<Rachael> Bruce: I'm OK with the language of the SC. I'm concerned with the definiton of status message. It ends with "or similar notifications" which is unbounded. What is in and what is out? The second point is the grammar seems messed up.

<Rachael> Steve: The last phrase shouldn't be in there. Let me paste in a clean version.

<Zakim> gowerm, you wanted to say that the role has to be appropriate to provide the presenation to AT

<Rachael> gowerm: Definition was not the latest.

Changes in content that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process, the existence of errors, or similar notifications.

<Rachael> Bruce: Can we strip out "or similar notifications?"

Changes in content that are not changes in context, that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process, the existence of errors.

<Rachael> Agreement it can be removed.

Changes in content that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process or the existence of errors.

Changes in content that are not changes in context, that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process, the existence of errors, or similar notifications.

<Rachael> AWK: What is the current SC text right now?

<Bruce_Bailey> add the oxford comma please

<steverep> epresent+SteveRepsher

Changes in content that are not changes in context, that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process or the existence of errors.

<Bruce_Bailey> Changes in content that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process, or the existence of errors.

<Rachael> Is this only the result of an action?

<Zakim> steverep, you wanted to ask if folks think chat logs are included in the definition

<Bruce_Bailey> With Oxford comma: Changes in content that are not changes in context, that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process, or the existence of errors.

<Rachael> steve: The three roles we want are the role of status (polite announcement announced atomically), alert role (assertive announcement), log role (chat logs, only new thing), and progress bars (all screen readers know how to deal with).

<AWK__> Ah, I was reading your earlier one. Don't worry, I'll make sure that the comma is in

<Rachael> Other things like a stock quote are meant for the marqui role. Timer, and others are not supported by screen readers.

<Rachael> Aria defaults are to ot announce those.

<AWK__> 10 minutes more on this to keep on track

<Rachael> ?: I want to make sure this is not just related to a user action.

<Rachael> No it's not.

<Kathy> I can

<Kathy> scribe: Kathy

<gowerm> Changes in content that are not changes in context, that provide information to the user on the success or results of an action, or the waiting state of an application, or the progress of a process, or the existence of errors.

Katie - needs to be result of the user action

<gowerm> Changes in content that are not changes in context, that provide information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors.

<Ryladog> Katie wants to be sure that this is NOT misunderstood to think it is only allpicable to the result of user actions

Alex - quick question, what about gaming

MG - let's read the definition

success or results of an action, or the waiting state of an application, or the progress of a process, or the existence of errors

Alex - so this doesn't cover what other users are doing

Alex - there are a lot of things happening and many players and computers

MG - gaming has a lot more issues than just this

Alex - since this is A and AA it does have a legal implication

MG - can be tackled by "the user action"

<AWK__> +1 to that

Alex - is there anything else essential

Brooks - what about other status updates and alerts

MG - there are some other SCs - pause stop and hid

<Bruce_Bailey> Seem pretty balanced to me

<gowerm> Changes in content that are not changes in context, that provide information to the user on the success or results of the user's action, on the waiting state of an application, on the progress of a process, or on the existence of errors.

<alastairc> An exception for 'time-based media'?

MG - does this address multi-user environments

Alex - hard to define user action since there is many thing happening

AWK - with 4 items that we need to get to, we need to decide if we can live with this or if it is not ready

scribe: anyone who cannot live with it

<alastairc> Is it missing a second part? I'm just catching up and looking at Mike's version above.

JF - can we see the final text

<AWK__> http://rawgit.com/w3c/wcag21/status-changes/guidelines/index.html#status-changes

<AWK__> Changes in content that are not changes in context, that provide information to the user on the success or results of the user's action, on the waiting state of an application, on the progress of a process, or on the existence of errors.

AWK - two options - discuss now or we have an understanding that we need to discuss on the list

scribe: we have until noon tomorrow

<Zakim> steverep, you wanted to suggest change in content which contains information about success, error, progress, or updates to a log and to

<JF> +1 to taking this to the list, as it seems to be down to edge and corner cases (and a bit of wordsmithing)

<lisa__> add a note that an exseption will be added

Steve - we can solidify the definition but gaming has more issues

AWK - alex is suggesting a note which is non normative

AWK - any objections

<lisa__> presnt +

RESOLUTION - leave open for final details on the list

accidental activation (https://github.com/w3c/wcag21/pull/595)

<gowerm> scribe: gowerm

<Kathy> 2.5.2

<steverep> http://rawgit.com/w3c/wcag21/accidental-activation-to-pointer-cancellation/guidelines/#pointer-cancellation

Steve: There are four bullets now [Reads them out]

<AWK__> http://rawgit.com/w3c/wcag21/accidental-activation-to-pointer-cancellation/guidelines/index.html#pointer-gestures

<alastairc> Wondering if the uses of 'function' might be better as 'action'? Function just seems quite wide for this context.

Steve: the poll request makes an editorial change. "Single pointers" removed "activation

AWK: There are definitions for down and up events.

MikeG: should abort and undo be separate?

<scribe> Unknown person: I dont' want to make it an exclusive "or" in abort or undo

Alastair: Is the use of "function" appropriate?

Steve: I'm referring to the functionality

Greg: When someone said "add in either", I wanted to make sure we don't say it has to be one or the other, not both

AWK: Do you think adding "either" makes that the case?

Greg: i think 'either' suggests Or not and/or

<AWK__> Completion of the function is on the up-event, and a mechanism is available to @@either@@ abort the function before completion or undo the function after completion;

Mike: I can live with it

AWK: Does anyone have additional concerns or comments?

<Greg> That is, "either ... or" suggests an exclusive or, which is not the intent here. (Personally I use "and/or" in my own work to be totally unambiguous.)

RESOLUTION: Accepted for CFC as proposed in pull request 595

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

<AWK__> https://www.w3.org/WAI/GL/wiki/Comment_Summary_2-6-1

<jallan> what happened to hover

AWK: the latest one is in the github draft

<JF> +1 to Jim's question - seems we skipped over Hover or Focus...

<AWK__> Functionality which can be operated by device or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, unless the motion is essential for the function and doing so would invalidate the activity.

<Kathy> All functionality of the content can be operated without requiring specific device sensor information, unless the device sensor is essential for the function and not using it would invalidate the activity.

Content on Hover or Focus (https://www.w3.org/2002/09/wbs/35422/ContentHoverFocus_20171109/results)

<AWK__> https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-14

<AWK__> When pointer hover or keyboard focus triggers additional content to become visible, the following are true: Dismissable: The user can dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure other content; Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved to hover the additional content; Persistent: The additional content r

AWK: The text that we have is the text in the wiki page

<AWK__> Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

<AWK__> Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

Steve: Last time we discussed, there was general agreement to remove "obscures"

Here is the link to the new version

<steverep> http://rawgit.com/w3c/wcag21/hoverable-and-persistent/guidelines/#content-on-hover-or-focus

Steve: I think there was confusion on the user experience that I tried to clarify. The only people who will notice these changes in experience are low vision users

<jallan> scribe: jallan

<gowerm> Alex: For devices not connected to a keyboard, what are the mechanisms to dismiss?

al: what are other mechanisms to dismiss
... without moving the pointer

<alastairc> ERr, how do you get hover on touch?

sr: hover is not done by touch. should not enter into scenario

<gowerm> Gowerm: Hover is not covered in a touch modality

al: if only applies to having a keyboard. then initial statement sounds like you want implementation on everything.
... need more clarity. not implementable

awk: can we cover this in understanding

<gowerm> Alex: But if I have a pointing device, the only way to satisfy dismissable is to move the pointer. it's saying I cannot move it

al: dismissable - not implementable if not keyboard

sr: if ua cant make it appear SC is not applicable

al: if I have a pen and no keyboard, or a mouse only computer and no keyboard... then I fail

<alastairc> You hover away from the trigger+content.

al: have mouse attached but no keyboard, do I fail dismissable.

author could cause right click to cancel hover

ac: moving away from content is a method to dismiss

awk: perhaps don't move focus

sr: how does 2.1.1 pass if you don't have keyboard. this is the same issue. splitting hairs

<lisa__> +1 rto steve. it is up to the user to plug in the keyboard

awk: if content you creates supports you are ok. author has no control of device.
... this scenario is not likely

<Greg> It would prevent an author from claiming conformance on certain closed systems.

al: many usecases. but closed product environment
... no a major problem. if closed environ. close out

sr: few mechanisems, on touch have gesture, or have triple click. ESC is usual mechanism

mg: or click on hover element, not impossible. if no keyboard there would need to be a mouse mechanism to do it.

al: still thinking?

awk: any other concerns?

mg: SC about fixing bad user experience

<steverep> +1 to accept

awk: any objections to accepting as in pull request?

+1 to accept

<lisa__> +1

RESOLUTION: accept for CFC based on pull request #569

close item 3

open item 6

awk: tomorrow at noon, will have CFC for items in working draft.

<alex> alastair, not much, probably seen in the browsers mostly

awk: have somethings not in a state to have in draft (addressed comments, etc.)
... purposes of controls, change of content, device sensors, some AAA items
... some items not decided.
... weeks ago, we decided to a) leave out, or b) use old lang and resolve any new comments. then these SC will go into Candidate review as AT RISK
... easy thing to do is see what can happen by tomorrow, and 6 don't make it.
... some will not get done by tomorrow
... contextual info, animation, timeouts -possible, interuptions minimum no cfc, purpose of controls no cfc, change of content -no cfc
... no one wants to give up on any of them.

ls: label them At RISK not remove.

awk: they will not be lost .... silver or 2.2

ls: make a survey that acts as cfc, if AT RISK or remove, understanding that no time for discussion

awk: happy to send out 6 CFC, to take out or AT RISK (leave as is)
... if we don't have concensus, goes in with last good wording. if we can get concensus wording by tomorrow then ok.

ls: contextual information has not been discussed. CFC for wording with no discussion.

awk: do we have concensus on wording, yes -- ok, no -- put in AT RISK?

<lisa__> can we first run a cfc if people can live with the current wording

<Zakim> gowerm, you wanted to say which one is being discussed specifically?

awk: not trying to change process

mg: sounds like Lisa trying to change process

awk: contextual info. chairs need to decide on proposed language after review of issues and emails. then CFC. and put out for concerns. need lots of comments.

ls: that's why suggested survey.

awk: don't have time

ls: a CFC survey

awk: that would be different from all other CFCs.
... as a straw poll

<Ryladog> +1

<lisa__> +1

<Kathy> +1

<alex> -1

awk: +1 to include old versions of non-concensus SC, -1 to remove non concensus ones

<laura> +1

<alastairc> +1, I'm assuming that negative comments knock them out unless we find time to discuss & get consensus.

<Bruce_Bailey> -1 inclined to omit

<Kathy> but mark at risk

<Brooks> -1

<steverep> 0, my answer is going to depend on the particular SC

<gowerm> -1 It really depends on the Scs

awk: AT RISK happens at CR not WD

<marcjohlic> +1 for awareness

<Greg> +1

<JF> 0

awk: slight weighting for includeing old lang.

<JF> yep... +0.4

awk: will review, send CFCs as necessary tomorrow
... also, 2 CFC for change of content. if new wording fails, then what happens - additional CFC

<Ryladog> +1 to new lang

kw: old lang is so different from new language. rather use new lang with a note rather than revert.

awk: add note with pointer to EDitor draft, review the new lang. but include the old language

ls: would be better to mark at risk but include new language. pointers etc will confuse reviewers as to what to review

awk: will think and do what we can.

<Bruce_Bailey> * is okay to hang out

awk: end of call. stay on to review other SC.
... 10 min on purpose of controls

close item 6

open item 5

<AWK__> http://rawgit.com/w3c/wcag21/purpose_of_controls_changes2/guidelines/index.html#identify-purpose

<AWK__> In content implemented using markup languages, user interface components that serve purposes identified in the Identified Common Purposes for User Interface Components section can be programmatically determined.

<lisa__> +1 nicer

purpose of controls

<JF> +1 to User Interface Controls

awk: make it only talk about UI components. need to change the handle

<lisa__> Iether ideify pourpose

<gowerm> I think if you make the title Common... then there is only one occurrence of "identified"

<lisa__> i like identify purpose

<laura> I like “Identify Purpose” too.

awk: in list of controls, there are definitions. some are marked at risk per yesterday call.

<lisa__> I think we should go with current list

<lisa__> would like to add mode back in ut i doubt there is time

awk: comment input controls consolidated terms. some also at risk
... questions... comment input controls - focus on user. not just any name.

<Zakim> JF, you wanted to suggest "Identify Common Purposes" (based upon the SC text that references Identified Common Purposes)

jf: user name vs other name as in airline reservation

<lisa__> +1

<gowerm> +1 makes sense

<lisa__> to iether name

jf: handle - id purpose

<Greg> +1 I like the proposal to rewrite the purpose list to clarify user, site owners, etc. Also "Identify Common Purposes" is also good.

js: metadata for form inputs, must be very clear
... technique use the autofill info available in browser

<Makoto> +1 to "Identify Common Purposes"

awk: please comment on things you can't live with

mg: close to SC language

<JF> +1 to the minmor editorial change (remove Identified from the body text)

<AWK__> In content implemented using markup languages, user interface components that serve purposes identified in the Common Purposes for User Interface Components section can be programmatically determined.

<gowerm> +1

<JF> +1

paste in wording

<AWK__> http://rawgit.com/w3c/wcag21/purpose_of_controls_changes3/guidelines/index.html#identify-purpose

In content implemented using markup languages, for each user interface component that serves a purpose identified in the Identified Common Purposes for User Interface Components section, that purpose can be programmatically determined.

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

ls: prefer without "common" in handle. too hard to understand

mg: common is important, focus on specific list not free form

<gowerm> Yes, controlled taxonomy idea is critical

awk: if can live, we are ok

<AWK__> http://rawgit.com/w3c/wcag21/purpose_of_controls_changes3/guidelines/index.html#commonpurposes

gl: what is change from previous draft

<lisa__> +1

<lisa__> In content implemented using markup languages, for each user interface component that serves a purpose identified in the Identified Common Purposes for User Interface Components section, that purpose can be programmatically determined.\

ls: purpose can be determined

gl: seems to look identical to original. but can live with it

Common Control Purposes

awk: one difference from changes2 - removed all of the atRisk items
... comment - may be covered by compose, is it start comment or submit comment

<Zakim> gowerm, you wanted to say I'm worried we're studing this list, but we haven't actually scrutinized the larger question. For example, there is no "confirm" which I just don't get

mg: worried about list, why no 'confirm' on every dialog

awk: specialize form of submit.

mg: like 'ok' button, confirming dialog box

<Greg> Lots of missing things, e.g. has First and Previous but not First and Last.

ls: many terms for submit....all merged

awk: be sure we won't have everything. but have important things
... can we live with current list.
... go with atRisk items or no atRisk

<lisa__> include the onses marked at risk

ls: keep them tin

mg: wyy different version of help, its all help

jf: chat help, faq help - different

gl: page with links for different help - chat or faq

mg: contact us page. how many are actions by mechanism.
... gethelp clarifies action.
... phone number generally not a link, not actionable

<lisa__> +1 with the at risks

mg: note should come out.

gl: leave in atrisk, favor granularity

<AWK__> If people want to put the AT RISK's in, +1, if not, -1

<laura> Leave them in. We can cut later if needed.

jf: can we add new items in January.

<lisa__> +1

<Greg> +1

<laura> +1

<gowerm> +1

<JF> +1

<Makoto> +1

<marcjohlic> +1

<Bruce_Bailey> +1

<AWK__> http://rawgit.com/w3c/wcag21/purpose_of_controls_changes2/guidelines/index.html#commonpurposes

<AWK__> http://rawgit.com/w3c/wcag21/purpose_of_controls_changes3/guidelines/index.html#commonpurposes

<AWK__> 2 has AT RISK items in, 3 doesn't

<Greg> Is there any major reason not to add OK/Accept?

awk: anyone want atrisk out

mg: remove not marked atrisk, how is remove different from delete. inclined to mark as atrisk

ls: ok with that

gl: have remove but no add

<alex> hard stop in 3mins

<JF> +1 to wordsmithing OnList

awk; micro managing. have other topics

awk: can we live with this at this time. can edit later per comments

gl: can we add items in Jan.

<lisa__> +1

awk: if things must be added, do it through the list.

<lisa__> +1

<Greg> +1 to add Add

awk: things without consensus will not be included as part of CFC

<JF> +1 to "Add"

<gowerm> +1

<laura> +1

<marcjohlic> +1

<JF> (+1 to "Confirm" too)

<Makoto> +1 to Add

Common Input Control Purposes

awk: is this all about USER INFORMATION

<lisa__> +1

awk: anyone not agree user information

no objections

awk: several at risk

<lisa__> (of the user)

<lisa__> email -email address (of the user)

awk: what is topic?

ls: we can take it out

awk: comment?

<JF> Topic is for email, or occasionally commenting (think Disqus)

ls: that;s were you add your comment

awk: neither is in autofill
... very different. not related to user

jf: these seem to be unique, topic of email, feels obvious to me.

<lisa__> (+1 to "Confirm" too)

ls: overlay for developer.

awk: comment is out, topic is out
... will edit branch and delete other branches.
... any comments to 7.1 list by 1130 tomorrow.
... 7.2 list came from autofill

<lisa__> org -the user’s company or organization

RESOLUTION: leave open pending comments to list by 1130 tomorrow

mg: much rather say - UserName, etc.

awk: use the list.

<Greg> Agreed, changing names to "User Name" etc. it would help clarify.

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

<AWK__> TPAC version? All functionality of the content can be operated without requiring specific device sensor information, unless the device sensor is essential for the function and not using it would invalidate the activity.

kw: tpac changes. two verison SR with minor changes, or tpac version

<Kathy> https://www.w3.org/2002/09/wbs/35422/resolving_device_sensors/results

sr: discussed a few days ago. motion actuation by AT in the note.
... other version with bullets

discussion of version history

<Kathy> https://www.w3.org/WAI/GL/wiki/Comment_Summary_2-6-1

<AWK__> <p><a>Functionality</a> which can be operated by device or user motion can also be operated by <a>user interface components</a> and can be disabled to prevent accidental actuation, unless the motion is <a>essential</a> for the function and doing so would invalidate the activity.</p>

https://github.com/w3c/wcag21/pull/378

<AWK__> <p class="note">This criterion concerns input through sensors which respond directly to motions such as tilting, shaking, or panning. It is not intended to cover indirect motion associated with operating a keyboard, pointer, or assistive technology.</p>

sr: from call a few days ago, wording changed to keyboard pointer.
... can live with any of these versions, as long as not the version in current draft

<AWK__> Functionality which can be operated by device or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, except when: • the motion is essential for the functionality and doing so would invalidate the activity. • the motion is used to operate a keyboard, pointer, or assistive technology

awk: moved note information (nonNorm) in to a bullet (normative)
... any concerns?

sr: none, I have none

gl: have a few

kw: no open issues

gl: editorial. 'can be operated by device or user motion'

mg: device motion would be good to clarify

<AWK__> Functionality which can be operated by device motion or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, except when: • the motion is essential for the functionality and doing so would invalidate the activity. • the motion is used to operate a keyboard, pointer, or assistive technology

sr: can't loose user motion

gl: moving anything is user motion. haptic feedback.

mg: use note to define User Motion

awk: when is a user motion a failure?
... if you remove pointer and keyboard motion, what is not covered

gl: no example

<gowerm> +1

awk; can we live with this language?

Functionality which can be operated by device motion or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, except when: • the motion is essential for the functionality and doing so would invalidate the activity. • the motion is used to operate a keyboard, pointer, or assistive technology

sr: or other accessibily supported device

<gowerm> yes

awk: ok with language?
... send out for CFC

<gowerm> +1 to cfc

<laura> +1

<JF> +1 to CfC

<Makoto> +1

RESOLUTION: accepted as amended above for Device Sensor

SR will update pull request

<Kathy> thank you

<AWK__> (see pull request 578)

https://github.com/w3c/wcag21/pull/378

sr: any change to handle

<Joshue108> thanks all :-)

awk: major scrubbing to happen.

<AWK__> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Accepted for CFC as proposed in pull request 595
  2. accept for CFC based on pull request #569
  3. leave open pending comments to list by 1130 tomorrow
  4. accepted as amended above for Device Sensor
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/11/30 18:52:11 $

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/.me wasn't you JF//
Succeeded: s/eithe'/either'/
Succeeded: s/snese/sense/
Default Present: MikeGower, JF, Joshue108, alex, MichaelC, Rachael, Bruce_Bailey, Greg_Lowney, Makoto, Brooks, AWK, marcjohlic, Laura, Katie_Haritos-Shea, Kathy, SteveRepsher, alastairc, Lisa
Present: MikeGower JF Joshue108 alex MichaelC Rachael Bruce_Bailey Greg_Lowney Makoto Brooks AWK marcjohlic Laura Katie_Haritos-Shea Kathy SteveRepsher alastairc Lisa
Regrets: David
Found Scribe: gowerm
Inferring ScribeNick: gowerm
Found Scribe: Kathy
Inferring ScribeNick: Kathy
Found Scribe: gowerm
Inferring ScribeNick: gowerm
Found Scribe: jallan
Inferring ScribeNick: jallan
Scribes: gowerm, Kathy, jallan
ScribeNicks: gowerm, Kathy, jallan

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

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]