<AWK> +AWK

<ChrisLoiselle> scribe: ChrisLoiselle

that better?

<JF> please advise the webex password, it is NOT the same as the one we used on Tuesday

<JF> thanks

<lisa> (trying to sign in..)

<lisa> +1 shoot the passwords

<AWK> Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List

I'll do next Tuesday , but need to sign off for 1pm sharp for another meeting

Undo : https://www.w3.org/2002/09/wbs/35422/COGA_undo/results

<lisa> wording has changed!!

<AWK> https://rawgit.com/w3c/wcag21/undo_ISSUE-38/guidelines/#undo

AWK: To Lisa, what would you like to do? Lisa, What changed?

Lisa: Scope is now part of SC. New language and exceptions added to address concerns

<david-macdonald> Is there a post to the list with the link to get in to webex?

<AWK> David: https://mit.webex.com/mit/j.php?MTID=md222811081e24ba7da9d428c5b5516e3

<david-macdonald> Presetn+ David-MacDonald

Lisa: Are there outstanding concerns?

<AWK> Users are provided with the ability to undo an action and to correct mistakes such that: The user can return to the location they were at, prior to the change in context, via labeled controls without unwanted loss of data unless the data loss is part of the correction; or the user can repair information entered, via labeled controls, and without unwanted loss of data unless the data loss is part of the correction.

<AWK> Exceptions: Where allowing the user to undo an action or maintaining data may cause harm such as adding risk to the user privacy or security. Where the user has confirmed an action it does not have to be reversible. Where allowing the user to undo an action may interfere with the essential function of the content. Where the action can no longer be controlled by the site.

<lisa> Users are provided with the ability to undo an action and to correct mistakes such that:

<lisa> - The user can return to the location they were at, prior to the change in context, via labeled controls without unwanted loss of data unless the data loss is part of the correction; or

<lisa> - the user can repair information entered, via labeled controls, and without unwanted loss of data unless the data loss is part of the correction.

<lisa> Exceptions:

<lisa> - Where allowing the user to undo an action or maintaining data may cause harm such as adding risk to the user privacy or security.

<lisa> - Where the user has confirmed an action it does not have to be reversible.

<lisa> - Where allowing the user to undo an action may interfere with the essential function of the content.

<lisa> - Where the action can no longer be controlled by the site.

JF: complex data form applications, some of the answers are in state, when you are trying to go back , you go back to the start of process rather than back one step.

Is this use case being addressed?

<chriscm> I don't see the addition of "User Agent Back Button" being used in place of/addition to "labeled controls". Are we relying on some definitions that I'm not privy to?

<chriscm> Can hop on queue if I need to, but thought this question was pretty simple.

<Greg> (The latest wording is also at https://rawgit.com/w3c/wcag21/undo_ISSUE-38/guidelines/#undo, the link in the survey.)

Lisa: Where use case is due to privacy, it is part of exception.

<AWK> *** concern about fully covering state changes in applications

JF: Doesn't seem to be addressing scenario where going backwards destroys state. Maybe we can address this in the privacy editorial section.

Mike Gower: Seems to be overlap on what Rachel is working on.

Lisa: We merged them.

Mike Gower: chance to confirm information was main point, thought that when they were separated , that they were easier to understand. I.e. confirmation screen.

Lisa: We haven't merged them, we are trying to make them consistent with each other.
... They are separated.

<chriscm> I am not sure what is meant by "Access key" as it pertains to going back on a mobile device...

<AWK> *** concern about explicitly requiring "labeled controls" - isn't this covered by other SC

Lisa: Access key or gesture is labeled to screen reader, but visually you won't know it is there.

Lisa, are you talking about voicemail or something else? Sorry. didn't catch word.

<JF> s/Its w3c for Thursday/

MikeGower: What happens with real-time transactions?

Lisa: Thought exception "Where the action can no longer be controlled by the site" would cover that scenario
... That exception was meant to include it.

ChrisCM: User agent back button action to suffice for "labeled control". I.e. mobile device buttons and access keys with built in functions actually trigger same action

<AWK> *** concern - would the back button be sufficient?

We should embrace this "back button action".

<lisa> +1

<JF> +1

<Detlev> +1 back button is well known even if not labelled

AWK: Would back button be sufficient?

<lisa> so we will take out labled controled as well

<KimD> +1

<Alex> is there audio?

<lisa> we cant here alex

<Alex> or is it just me?

<lisa> just u

<AWK> my audio cut out

yes

<Alex> i'll call back

<gowerm> my audio cut. redialing

AWK: dropping to call back in.

<KimD> *My audio dropped

<Zakim> Greg, you wanted to say I thought that other SC can be conformed with by providing keyboard-only commands. If that is correct, why make this one be different by requiring labeled

Michael: to Greg, no audio. Greg has dropped.

<Greg> No audio at the moment; trying to reconnect.

Lisa: We will get rid of "labeled controls" in SC

<gowerm> unable to dial back in.

Alex: clarifying question on what do you mean by a "a new context", i.e. prior location?

Lisa: the location they were at before they pressed the wrong thing.

Alex: Is this same as change of context vs. change in context?

We need this to be clearly defined.

Lisa: Will work on wording of this portion of text

Alex: Timing as an issue, i.e. allowing undo in perpetuity is not something we should endorse. Some sort of time /session boundary needs to be addressed.

<chriscm> +1 to "unwanted" comments.

The text "Unwanted" is still there. How is this defined?

Alex, what was the last comment you made? I was typing the other.

<lisa> we agreed to remove the labled controls

<lisa> it is done

Alex: You can undo a typing error by hitting backspace. I.e. regular typing would not be counted as an action. Or you wouldn't have to label those instructions. I.e backspace or shift + tab or control + Z

<AWK> *** concern about undoing typing with backspace.

<lisa> time reminder

<Zakim> alastairc, you wanted to ask if there is a simpler way of wording it (with suggestion)

<Pietro> Audio in WebEx by browser dropped, now audio works by desktop application

<alastairc> Users can undo an action by returning to the action, and correct data entry by repairing the information entered without unwanted loss of data except when:

<Detlev> scoping: "applies to actions that call up new page or change page content"?

<david-macdonald> is there a link to latest text?

<david-macdonald> is it here? https://rawgit.com/w3c/wcag21/undo_ISSUE-38/guidelines/sc/21/undo.html

AlastairC: what is missing to what I pasted in IRC?

One is undoing action and the other is correcting input?

<gowerm> so 'remove "returning to the action'

Lisa: going back is going to be difficult. I.e. filling shopping cart , you can edit shopping cart at end rather than updating amount of lemons on lemon's add page.

<Greg> David, the text at that link does not reflect removing the labeling requirement or any other changes from this call.

Alastair: Is it data or action? Needs clarification.

<david-macdonald> Is there a working text we are looking at?

MikeGower: What is difference between correct mistakes and repairing information?

Lisa: correct mistakes is a wider scope

<gowerm> Users are provided with the ability to undo an action or correct mistakes such that the user can return to the location they were at without unwanted loss of data unless the data loss is part of the correction.

<chriscm> Can we changed "without unwanted loss" to "without required loss"

<chriscm> required being defined as: security/password, etc... many of the things listed in the Exceptions.

<david-macdonald> "Users are provided with the ability to... could be "A mechanism is available to..."

AWK: Talks to scenario where you are booking a course. Choose location first, then course is not available in another location.

<alastairc> I thought that data loss that is part of the correction would "wanted".

<Greg> That new, simplified wording does not address privacy/security concerns, or things that are no longer mutable, etc., etc.

<lisa> Users can undo an action by returning to the action, and correct data entry by repairing the information entered without unwanted loss of data except when:

Mike Gower, did you want me to note that concern here?

RESOLUTION: Leave open for further edits from Lisa, Mike and Alastair

<gowerm> I'm concerned we are not looking at more 'ready' SCs.

Personalisation: https://github.com/w3c/wcag21/issues/6

<gowerm> Such as Confirm Importnat Information

<lisa> gregg can you wemail me your issue?

AWK: Greg, do you want to speak to Programmatically Available to the forum?

GregL: In User Agent guidelines, we have developed a definition that is much more specific for Programmatically Available

<AWK> Programmatically available: Information that is encoded in a way that allows different software, including assistive technologies, to extract and use the information relying on published, supported mechanisms, such as, platform accessibility services, APIs, or the document object models (DOM). For web-based user interfaces, this means ensuring that the user agent can pass on the information (e.g. through the use of WAI-ARIA). Something is programmatically available

It is in part for the AT to be able to work correctly

<AWK> ...if the entity presenting the information does so in a way that is explicit and unambiguous, in a way that can be understood without reverse-engineering or complex (and thus potentially fallible) heuristics, and only relying on methods that are published, and officially supported by the developers of the software being evaluated.

<david-macdonald> https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

<david-macdonald> https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head

AWK: One of the challenges about personalization is : what items / bits of data are we talking about specifically? COGA talks to things that are in draft form.

<david-macdonald> https://www.w3.org/TR/WCAG20/#programmaticallydetermineddef

If there is not support for tooling to take advantage of this data, then there is testing concerns related to this.

<lisa> i am on mute

<david-macdonald> programmatically determined (programmatically determinable) determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities

<david-macdonald> From WCAG

<lisa> lol, easly confused...

Authors are putting work into a page and can't demonstrate what it does, we may have to require a hook to meet it half way.

<chriscm> +1

JF: The way this is being structured now, the title attribute would satisfy this success criteria per normative...

<alastairc> So why isn't that a problem for 4.1.2?

<lisa> exactly alister

We are creating a loophole via the title attribute

<JF> The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the image credit or a description of the image; on a paragraph, it could be a footnote or commentary on the text; on a citation, it could be further information about the source; on interactive content, it could be a label for, or instructions for, use of

<lisa> it iis the samw

DavidM: Programmatically determined vs. available...introducing a new term may add more confusion

<JF> +1 to David

Lisa: asks for clarification

David, did you mean that this causes ambiguity?

<gowerm> +1 fixed taxonomy

<alastairc> JF but 4.1.2 doesn't specify the taxonomy either

<AndroUser2> +q to speak to John's example

<chriscm> +1 taxonomy

JF: Working from a fixed taxonomy currently. The introduction of title=button , which is legitimate is not useful

<chriscm> Getting a bit heated...

<Greg> ...would be the former, but not the latter.

I'm losing the conversation. sorry.

<lisa> me to chriss

The way it is written, contextual information is available, what does that mean?

<lisa> https://github.com/w3c/wcag21/issues/6 has these terms defined

<AWK> contextual information: https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/terms/21/contextual-information.html

<gowerm> contextual information

<gowerm> Proposed

<gowerm> The concept; role; importance for simplification; information that clarifies the meaning; relationships to other elements; position in a process; process of which this element is a part

Lisa and JF, Could you please provide your comments in text within IRC, I lost the point trying to keep track. I just want to list what you said correctly.

<gowerm> That definition is a mess, IMO

<Greg> Is the wording at the top of the Issue 6 page still the currently proposed wording?

<alastairc> @Greg from the link at the top, not the text under SC text.

<marcjohlic> Trying to understand if the things listed in this definition are AND statements or OR statements.. It's not clear to me

Jason: I don't think specifying it in WCAG unless you are sure of the scope, I don't think it should be included at the moment. These may be met within the schedule, but I don't think they are there yet

<alastairc> Common navigation elements, common form elements and common interactive controls can be personalised by:

<alastairc> - a mechanism that enables the user to add symbols OR

<alastairc> - contextual information that can be programmatically determined.

<AWK> Scribe: AWK

Alastair: not sure how this is different from 4.1.2 specifying N/R/V

<ChrisLoiselle> Thanks, AWK. I'm ok to drop?

<Zakim> AndroUser, you wanted to speak to John's example

<ChrisLoiselle> thanks.

Josh: John's title example is important
... in the past AT didn't have a way to support some information and the title attribute was used
... but now with the HTML5 spec the title attribute is better, but still broadly defined.

<JF> +1 to Josh

<JF> As in this example: <a href="" title="The history of the ACME Company">About</a>

<lisa> josh did you read the definition of context?

<alastairc> Lisa: The last gap from my point of view is there there doesn't appear to be any user-side technology, even in development, that would use the meta-data part of it.

<lisa> there is a few things happnign alister

<Zakim> Greg, you wanted to say The key question we need to answer first is: do we want to require the page to provide info that is human-understandable (WCAG's "programmatically

<AWK_> Greg: is the goal to have human-usable or computer-usable information here?

<AWK_> ... this definition for contextual info starts to sound like computer-usable, but then it gets confusing

<lisa> i am happy to add a deffiniton for computer-understandable

<AWK_> *** concern that the computer-usable focus needs to be addressed, per Greg's comment

<gowerm> +1 to effect on ecosystem

<Greg> My point was that the key question we need to answer first is: do we want to require the page to provide info that is human-understandable (WCAG's "programmatically determined"), or that is computer-understandable (UAAG's "programmatically available")? That is, do we only intend for AT to pass it on to the user, or to use it to make decisions, carry out actions, and alter the content? Info...

<Greg> ...in TITLE would be the former, but not the latter. I feel the definition of "contextual information" starts by implying it's the latter, but is not rigorous enough about it as it only gives examples of such.

<lisa> the ecco system wont mature becuse there is not enough content

<lisa> and now with aria the blind can use web apps

<AWK_> Chris: there are issues that remain from undefined use of semantics for role, we might be headed that way here too

<lisa> a lot of the time

<lisa> but coga cant

<alastairc> Hmm, I think there is a hangover of perceptions from previous versions of the SC + info. I'll try and clarify on list.

<Joshue108> I'm here 2..

<Joshue108> +1 to continuing

<lisa> do we see a point in trying to work this out

<JF> +1 to David - ask for whart you really want, and don't try to widen the circle so wide that it gets us nothing

<JF> For this to really work, it needs a fixed taxonomy.

<lisa> mike you have seen the working draft

<lisa> ?

<gowerm> Yes, I have. I've been commenting on it in the issue thread for the last 6 months.

<Joshue108> John, what is the difference between your suggestions of a taxonomy and Lisa's COGA semantics?

<Joshue108> Are both not effectively APIs?

<JF> None... that's the point. I stated in my email that I'd much rather make this a AAA today, and 'demand' coga-semantics, rather than try and make this a single A with such a broad scope that using @title *DOES* meet the technical requirement but in practice doesn;t address the real need

<Joshue108> Ok, I get you.

<Joshue108> I see the sense in that point, also made by David..

<Joshue108> So go all in.

<JF> As I noted, if we as a group *do* accept that using @title meets the functional requirement today, then carry on. Just understand the consequences of that decision

<chriscm> @Joshue108 and @JF I don't think he's saying they are different. I believe he's suggesting they aren't mature enough, or widely adopted enough to provide a real solution. It's like trying to hammer in a nail, but you only have the handle of the hammer. And it's a pretty flimsy handle at that.

<Joshue108> They would need to mature..

<Joshue108> Right Chris

<JF> exactly. I mean, wiht no offense to that TF, the draft spec has all kinds of incomplete gaps in it now

<gowerm> And I have argued that we can include coga techniques to bring them to enhance adoption and help improve maturity without this being a requirement, just like we did with ARIA.

<Joshue108> Right, then that needs to be water tight to strengthen the case for adoption

<Joshue108> +1 to Mike

<Joshue108> I'd be happy to support that..

<gowerm> There is STILL not requirement to use ARIA, a much more mature spec, and yet we have lots of adoption, etc. Why can that not be the approach?

<Joshue108> Just don't want to require an insubstantial API

<Joshue108> Or immature..

<Joshue108> It would weaken the whole project

<gowerm> And no infrastructure to support it

<Joshue108> Unless we define user requirements that can be supported by independent APIs if devs want

<Joshue108> But they would need a steer..

<AWK_> trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/this pwd doesn't seem to work??? w3c-wai-gl//
Succeeded: s/the other pwd is for Tuesday. Its w3c for Thursday//
FAILED: s/Its w3c for Thursday//
Default Present: AWK, ChrisLoiselle, JF, KimD, lisa, MichaelC, chriscm, alastairc, Greg_Lowney, Detlev, Pietro, MikeG, David-MacDonald, jasonjgw
Present: AWK ChrisLoiselle JF KimD lisa MichaelC chriscm alastairc Greg_Lowney Detlev Pietro MikeG David-MacDonald jasonjgw
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Found Scribe: AWK
Inferring ScribeNick: AWK
Scribes: ChrisLoiselle, AWK
ScribeNicks: ChrisLoiselle, AWK
Found Date: 13 Jul 2017
Guessing minutes URL: http://www.w3.org/2017/07/13-ag-minutes.html
People with action items: