<AWK> +AWK

<lisa> can someone ping me the pass word on the private chat

<lisa> thanks got it

<scribe> scribe: ChrisLoiselle

Concurrent Input Mechanisms https://www.w3.org/2002/09/wbs/35422/MATFSC_june/results#xnew1

AWK: Opens discussion on Concurrent input mechanisms. Feeling that per survey responses, may not be ready. Should we push out to Silver?

<Joshue108> https://github.com/w3c/wcag21/issues/64

Joshue O: Kathy may have comments as SC manager on this.

<Joshue108> JOC: We should defer until she is here.

<steverep> Should we be discussing Greg L's alternate more specific proposal instead?

JasonWhite: Scope and requirements need to be made clearer.

<kirkwood_> sorry i haven’t been able to webex in. others may be having problems fyi

JasonWhite: Please see my survey response
... definition of input mechanism needs to be addressed, tied to the types of events.

<alastairc> I like the direction GregL went in with his survey response, that seems possible. "The presence of one input device or modality on the system, or the user having used that device, does not prevent the use of any other device for performing subsequent actions".

<Zakim> Greg, you wanted to ask if for feedback on the revised wording that I'd proposed, and whether anyone prefers the original

<Greg> "The ability to perform an action using a given input device or modality is not restricted due to either of the following: (a) the presence of a different input device or modality on the system; (b) the user having used a different input device or modality at a previous time." That does not require that a touchscreen be supported, but it cannot be disabled merely because a mouse is present...

<Greg> ...or has been used. Alternate wording might be "The presence of one input device or modality on the system, or the user having used that device, does not prevent the use of any other device for performing subsequent actions"

<AWK> Greg's proposed changed wording

GregLowney: raises question on alternative wording

David-MacDonald: Greg's proposal is helpful. I.e. don't get in the way of other "stuff". Question is how would we test this ?

AWK: What are the types of problems we are attempting to solve with this ?

<laura> Agree with David. Would be difficult to test.

<alastairc> Patrick's explanation: https://github.com/w3c/wcag21/issues/64#issuecomment-273880125

Joshue O: If user was to switch input devices that the flow would not disrupt the user.

<Joshue108> I think this is more of a user agent issue,

<laura> Is it an A11Y problem or a usabity problem?

<Joshue108> But I'd prefer to have Kathy here to comment..

David-MacDonald: I was on mobile calls, Kathy may have more input in terms of this issue.

<Zakim> steverep, you wanted to ask how this can be done? Isn't this a privacy issue for most input devices?

<alastairc> Suggest we defer to when Kathy is back. Doesn't seem like it will be missed for now.

Steve R: Back to AWK's question, how can it be accomplished in code? Goes into mouse vs. keyboard device privacy issue.

JasonWhite: We need a strong accessibility case for this to be introduced. Needs clarity in terms of whether it belongs here as currently written.

Marc J: When using different AT, web page or content may be set up to handle ...more about devices rather than input.

<steverep> Content has no way of knowing I'm using a screen reader or magnifier though

AWK: Kathy may have better answers on this. Per Josh's thoughts, we should have Kathy talk to the points as to benefits of the issues.

RESOLUTION: Leave Open

Support personalization (minimum) https://www.w3.org/2002/09/wbs/35422/COGA_new/results#xq4

<AWK> Current version: https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/#support-personalization

AWK: Is the text on branch of rawgit the latest?

Lisa: yes.

AWK: Critical features, core, essential...question is on how would we do this? I.e. page shows only what is "core" OR aspects of the page that are "core" are indicated programatically

<AWK> Current wording: For pages that contains interactive controls or content that is not core, one of the following is true: a mechanism is available for personalization of content that removes non-core functionality and content, and enables the user to add symbols to interactive controls for core functionality, or core functionality and content, and contextual information for core functionality and content, is programmatically determined.

Lisa: contextual information vs role : Button functionality sends..how do I know this is the send button? It has text that say's its a send button. Undue , Reset. You need to know what they button is programatically.

<Greg> Ah! You meant "programmatically determinable", or "can be" programmatically determined, not "is" programmatically determined! Completely misled me.

<alastairc> Yes, I think it means "can be programmatically determined" at the end of the SC.

Lisa: Some users have issues with language, but understand symbols. The correct symbol for the user can be loaded. Can open communication for people who struggle with this.

Core functionality can be mapped to something they can understand.

<Joshue108> -q

First bullet point of proposed criteria, allows the site to do it. Done in any technology. Not dependent on any existing techniques.

<Zakim> JF, you wanted to ask who determinw shat is "core" and how is that determination made?

JasonWhite: Asks editors and chairs to make sure we have correct text in surveys so comments can be made appropriately to latest text.

<KimDirks> +1 to making sure the survey reflects the right language

<Greg> +1 to Jason's comment that we need to improve our processes to avoid having people review the wrong draft

JF: Core vs. non-core: How is this measurable? This tends to be subjective on user.

<Zakim> Joshue, you wanted to ask can existing semantics like main be used?

JF: In context, this is hard for author or tester to understand what "core" is. It is the user that decides that on personalization.

Joshue O: Semantics of this, do you see bespoke COGA semantics being used to support this or other type of semantics?

<laura> +q to say 1.) Maybe instead of using the word “core” use the word “essential” as that is aready defined? 2.) To me personalization may work better as techniques for SCs. This would be similar to how ARIA was added to WCAG as techniques.

Lisa: We based definition of "core" on page title. We are depending on that. Does page title fulfill its purpose? Core is equally testable between core content and page title.

<alastairc> Page title: "My account" (page includes your info, list of services you use, adverts, etc etc.)

<Joshue108> Yeah - a title may not reflect core.

Lisa: Non-core: has nothing to do with page title. If content is non-core, some of it at least, is removed. Don't worry about edge cases. Remove only what is not directly related.

Joshue O: Page title may give you an architectural review of page : See Alastair's example on "My Account".

<JF> What is "core"? For many users, it could be argued that "footer" content isn't core. Yet the General counsel of the XYZ Widget company may disagree - that the Copyright notice on the site/page is "Core" and critical

<alastairc> Core issue with "core": It cannot apply to all web pages.

Lisa: Page title is meant to describe purpose of page. Page title could be considered subjective.

<Zakim> AWK, you wanted to ask JF whether he has the same concerns about "essential" and feels that it is evaluated by the user vs. author

This SC helps with cognitive noise.

AWK: There are pieces of WCAG 2.0 that are "subjective". I.e. page title , alt text for an image. Focused on a specific item. Page title is going to generalize what page is about.

<Zakim> MichaelC, you wanted to say I´d like to leave some wiggle room and be ok with it and to say the page title thing is ¨for example¨ and to say avoided ¨essential¨ because

AWK: What constitutes core content and who makes that decision?

Michael C: Core was introduced as to avoid using "essential".

<Zakim> laura, you wanted to say 1.) Maybe instead of using the word “core” use the word “essential” as that is aready defined? 2.) To me personalization may work better as

Laura, I missed your point, could you recap in text? Sorry!

<laura> Maybe instead of using the word “core” use the word “essential” as that is aready defined?

<laura> https://www.w3.org/TR/WCAG/#essentialdef

<laura> The basic test is “can you remove it?”. Authors (site owners / designers etc) get that.

<laura> To me personalization may work better as techniques for SCs. This would be similar to how ARIA was added to WCAG as techniques.

Thank you!

Lisa: The method is that we put this in, then we perhaps merge it with 4.1.2. To tweak the SC, we have to put this in and then tweak.

<alastairc> How about "Non essential controls or content can be programmatically determined."

* 4.2.1...

Lisa: Define context, with what we need.

<alastairc> Sounds like: the adjustment would be: Context would be added to 4.1.2, and / or remove 'or available in text' from 1.3.1.

JF: Alternative text, subjectivity is at client's level.

<lisa> This could do it ---4.1.2 Name, Role, Context, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name, role and context can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user...

<lisa> ...agents, including assistive technologies.

JF: Add blockers , are they core to the page? Without the ads, the website is not able to be kept up. We need this for revenue, who's right? Accountant or end user?

<Zakim> bruce_bailey, you wanted to disagree that page title describing topic or purpose is ambiguous in a way compareable to core or essential

Bruce B: "core" vs. "describe topic or purpose" , seems world apart in ambiguity.

Take a paragraph rather than a the whole page, what is considered "core" in a paragraph? Core functionality of a web page and removing that is a much larger question. Hard to evaluated.

<Joshue108> +1

<Joshue108> Much better IMO

<JF> Are page ads "core" to a page?

<Joshue108> only if you are sellin something..

Lisa: What if we got rid of "core" ?

<JF> precisely Josh

<kirkwood_> if the button said “click here"

AWK: send button the same thing as submit ?

Lisa: Contextual information related to button is needed.

<Joshue108> Actually John Kirkw point is interesting, would click here buttons etc be good for COGA users, even though they are not good for VIPs?

<Greg> Can we have Lisa's new wording in IRC?

<Joshue108> but we dont want specialist semantics to describe generic controls!

AWK: does ARIA allow for describing submit button vs. regular button? Lisa: Microdata is available. JF: Aria-Label. Michael C: not a semantic mapping in aria specifically to Andrew's question.

<bruce_bailey> I do not think it is constructive to try and write this up from scratch on the call

Alastair C: Page title can describe my account, but different content on page would be confusing on what would be considered "core".

Alastair C: Brings up wording of non-essential ...

<alastairc> "Non essential controls or content can be programmatically determined" was one

Two separate SCs.

<Zakim> Joshue, you wanted to say is it not better that non-core stuff just doesn't get in the way?

<JF> +1 to Josh

<AWK> +1 to josh's point about requiring solid semantics

Joshue O: Are we taking wrong approach to this? We need strong semantics

<KimDirks> +1 (good semantics)

<laura> +1 to strong semantics

<lisa> For pages that contains interactive controls, or more then one region one of the following is true:

<lisa> - a mechanism is available for personalization of content that enables the user to add symbols to interactive controls for core functionality,

<lisa> - contextual information for regions and essential controls is programmatically determined.

<alastairc> JF - we have a defintion, and it is essential to the page, not the user

<Joshue108> I'd be happier to see more of a focus on symbols and interactive controls for core than anything else in this SC.

<lisa> For pages that contains interactive controls, or more then one region one of the following is true:

<lisa> - a mechanism is available for personalization of content that enables the user to add symbols to interactive controls

<lisa> - contextual information for regions and essential controls is programmatically determined.

<lisa> do people prefer this?

JasonWhite: Identify things for what they are. But "essential" should be out of the author's hands.

<lisa> question: can we leav in contextual information for regions and essential controls is programmatically determined.

<alastairc> For those who haven't seen it, these are the contextual roles being proposed: https://w3c.github.io/personalization-semantics/#adding-context

What happens when authors get ARIA semantics wrong?

<bruce_bailey> WCAG2 uses web page as the unit of conformance, but SC apply element-by-element

<Zakim> bruce_bailey, you wanted to ask that this SC be drafted in a way that be applied element by element rather than the whole page

<lisa> question: can we leav in contextual information for regions and essential controls is programmatically determined.

<AWK> Some SC refer to the whole page - e.g. "all functionality is available from the keyboard"

<Zakim> steverep, you wanted to ask how "core" is different from the ARIA main landmark, and why that simple definition is okay if the one for core is not

Bruce B: easy to point to the items that are failing, but not sure we are there for this SC.

<alastairc> Lisa, I think this would take on Bruce's comment: For interactive controls one of the following is true:

<alastairc> - a mechanism is available for personalization of content that enables the user to add symbols

<alastairc> - contextual information essential controls can be programmatically determined.

Steve R: Core content may not be as subjective as some people are stating. I.e. ARIA main landmark? Is that any different.

<AWK> Main is defined as "The main content of a document"

<alastairc> The concept of 'main task of a page' is not universally applicable.

<lisa> For pages that contains interactive controls, or more then one region one of the following is true:

<lisa> - a mechanism is available for personalization of content that enables the user to add symbols to interactive controls

<lisa> - contextual information for regions and essential controls is programmatically determined.

Lisa: What do you prefer?

James N: What is an essential control in web applications? Different users use different controls.

<lisa> essential controls: controls that are nessisary for completion of the main porpose of the web page

Lisa: Main purpose of page is to send an email. Label of button says "send". That would be an essential control. (Lisa hope I summarized your idea correctly).

<alastairc> This has to apply to *all* pages, we don't get to pick and choose.

<bruce_bailey> sorry, have to go

+q : If a page had an aside element, which could be considered separate from main content, should all asides be removed from "core"?

<alastairc> For the essential controls, can we work in reverse, where anything given a role (from ARIA or

<alastairc> https://w3c.github.io/personalization-semantics/#adding-context), is known, and unknown controls are not essential unless marked as essential?

JF: As content authors or evaluating websites: If all buttons are in menu element, which do we remove?

Lisa: We took essential controls out, except for second bullet point.

Reduces author's burden.

Lisa: Adding symbols or changing text to something user understands.

JF: We need to do this without using COGA semantics.

Lisa: Many different ways of doing this without using COGA semantics. RDF, etc.

<laura> Contextual information:

<laura> semantics and tags that give meaning to the content such as context of elements; concept and role; relevance and information for simplification; position in a process

<laura> https://github.com/w3c/wcag21/issues/6

Lisa: Contextual information needs to be included. Link inside a menu is not what we mean. We mean a concept.

<KimDirks> * where is definition for "contextual information" Do you have a link?

<laura> contextual information

<laura> Proposed

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

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

AWK: should we leave open?

<lisa> essential cntrols are controls taht are nessisary for the task that a user may have come to the page for

RESOLUTION: Leave open

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

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)

Default Present: AWK, jasonjgw, KimDirks, JF, MichaelC, kirkwood_, Greg_Lowney, ChrisLoiselle, Melanie_Philipp, Makoto, Rachael, steverep, bruce-bailey, alastairc, David-MacDonald, Laura, Mike, Elledge, Pietro, Katie_Haritos-Shea

WARNING: Replacing previous Present list. (Old list: (no, one), jasonjgw, KimDirks, JF, MichaelC, kirkwood_)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK, jasonjgw, KimDirks, JF, MichaelC, kirkwood_

Present: AWK jasonjgw KimDirks JF MichaelC kirkwood_ Greg_Lowney ChrisLoiselle Melanie_Philipp Makoto Rachael steverep bruce-bailey alastairc David-MacDonald Laura Mike Elledge Pietro Katie_Haritos-Shea
Regrets: Wilco Jake Detlev KathyW Glenda Denis_Boudreau Jeanne
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Found Date: 27 Jun 2017
Guessing minutes URL: http://www.w3.org/2017/06/27-ag-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.