<ChrisLoiselle> scribe:ChrisLoiselle

Conformance Challenges doc

AlastairC: Asks for contributions in Github around issues. Opens to Janina

Janina: Observations from me on how we would adapt the document. Reformatting of appendix , was originally in body of document

<Chuck> ach Ch

<Zakim> Chuck_, you wanted to end meeting

Janina: On the challenges , we are open to additional ideas for people who want to work on this.
... Timeline, we are looking at January.

PeterK: On timing, does AGWG have comments as to when that would be available?

AlastairC: We have other priorities , depends on what issues are raised and how we deal with them.

PeterK: We have few issues. More comments than changes. Other than refactoring silver research into other parts of documents, it feels like we can have another draft in Q1 and then a final note.

Would that align with AGWG's calendar?

AlastairC: Yes. We could propose survey from a meeting and see where it progresses.

December 22nd Meeting

<david-macdonald> Yes

<GN015> yes for Gundula

<PeterKorn_> no

<DavidASx> No

<MelanieP> yes

<sajkaj> -1

<sarahhorton> No

<Francis_Storr> 0

<Nicaise> -1

<JF> 0

<morr4> +1

<Detlev> unlikely

<Sukriti> 0

<kirkwood> no

<Chuck> 0

<juliette_mcshane> +1

<Fazio> +0

<Caryn-Pagel> -1

<Fazio> could use a break

<GN015> what about Dec 29 and Jan 5 ?

<Chuck> -1 for me Dec 29

RESOLUTION: Last meeting of 2020 is on the 15th, 1st meeting 2021 is Jan 5th.

<Chuck> alastair: ...working out calendar...

Hidden Controls https://www.w3.org/2002/09/wbs/35422/hidden-controls-12-2020/results

<ChrisLoiselle_> scribe:ChrisLoiselle_

<Chuck> alastairc: Our first item of review is the results of hidden controls issue.

<alastairc> https://docs.google.com/document/d/1v9VN9JN7fWIv1fIlBNXRhibMnRavn0M2Bx6AohtZ_jc/edit#

<Chuck> alastairc: proposal in survey and in google doc.

AlastairC: Pastes google document

Results mostly positive. Justine had a comment, but sent her regrets.

<alastairc> "Information needed to recognize how to operate user interface components is provided to users without requiring pointer hover or keyboard focus."

AlastairC: reads through fall back 2 on Google doc . Opens to comments on call.

<alastairc> Justine's comment: I still have concerns with the scope of a "process" following W3C's current definition. The SC seems problematic for interfaces such as web-based word processors, where any number of buttons appear on-screen and are available for use during the document editing process. If an exception were drafted to address these types of scenarios, that would resolve my concern.

DavidM: Mine should be the same.

Justine: From comment in document, has question on scope of a process.

Rachael: Exception seemed to be missing.

<AWK> +AWK

<alastairc> Exception that Rachael suggested: "Equivalent: The control is available through an equivalent control on the same page or on a different step in a multi-step process"

Rachael: I believe it should be in both places.

AlastairC: If you can do something by another means, then it should pass. Talks to gmail hover scenario.

At a page basis, you wouldn't be able to rely on something that isn't on that page. Did anyone have comments on that?

Detlev: I still think someone that called hidden controls should be defined more clearly. Simple terms. I.e controls shouldn't be hidden by default.

AlastairC: How about visible to users...

Detlev: Or not hidden from users. Hidden is the core of the SC.

Rachael: How about flipping it to visual controls?

<Detlev> +1 to "visible controls"

DavidM: We landed on information needed vs. the control itself. I.e. a x inside a tooltip. It may be hidden until the user tabs to the tool tip.

Information needed might be the control or may not be.

<Detlev> Thanks, I appreciate the explanation

That is why we didn't get into the word hidden. I.e. provided instead.

<david-macdonald> +1 on visible controls

AlastairC: The Visual controls aspect is a positive version, that might help with Detlev's question.

<Ryladog> +1 to that approach

<mbgower> Visible controls: Information needed to identify user interface components is visible without requiring pointer hover or keyboard focus.

MikeG: Hidden controls is not a good title. Typed his comment into IRC.

<alastairc> Current status: Use mbgower's version above, + exception for "equivelent"

<david-macdonald> +1 on "is vbisible

<Rachael> +1

<mbgower> Information needed to recognize how to operate user interface components is visible without requiring pointer hover or keyboard focus.

<alastairc> Add: Equivalent: The control is available through an equivalent control on the same page or on a different step in a multi-step process

MikeG: I think that it would be what I pasted in.

AlastairC: I think that covers everything so far.

Gundula: I have an issue with equivalent ...step vs. multi step process . Is it available in earlier step or later step? Should only be on same page.

AlastairC: tabbing through all your items in your inbox. Accelerators shouldn't be banned...

<Rachael> Suggested update for Equivilent: The functionality is available through an equivalent control that is visible on the same page or on a different step in a multi-step process without requiring pointer hover or keyboard focus.

Rachael: As written originally you could have two controls, which wouldn't work.

Gundula: What is the requirement of multi step process part?

Rachael: If you walk through the mailbox , there are shortcuts available. The controls are visible in one of those steps, but not all of them. We didn't want to penalize people for providing shortcuts.

Gundula: Multi step process definition should be included in understanding.

My thought of multi step is different than what someone else may thing of multi step process.

AlastairC: Opens to Katie.

Katie: If we take visible controls and talk to keyboard focus. Doesn't that prevent the skip nav functionality? Does that have to be an excemption?

DavidM: It is an exception.

Katie: Thanks, perfect.

DavidM: SC revolves around information needed vs. functionality available. We are getting away from SC when talking to functionality. Information to understand is available text should be talked to ...
... I will add in Rachael's comment.

<Zakim> mbgower, you wanted to say The functionality is available through an equivalent control that is visible without requiring pointer hover or keyboard focus.

MikeG: We have SCs...multiple ways, isn't done on a single page.

Rachael: We can exempt controls ...

MikeG: Main reason this exists is due to mouse and on hover.

AlastairC: Could you add me as an editor?

DavidM: should be able to edit now.

<alastairc> https://docs.google.com/document/d/1v9VN9JN7fWIv1fIlBNXRhibMnRavn0M2Bx6AohtZ_jc/edit#

David and Alastair edit document live. Talk to last exception bullet.

The functionality is available through an equivalent control that is visible on the same page or on a different step in a multi-step process without requiring pointer hover or keyboard focus

DavidM: The third bullet , information needed to recognize text , I'm open to solutions on phrasing.

<AWK> Seems like if you can do something in a few steps then it isn't really required to proceed in the current step.

DavidM: Functionality of user interface component is available ...as an user interface control...

Rachael: An equivalent control on the same page or on a different step in a multi-step process passes the SC.

<Zakim> Rachael, you wanted to suggest "An equivalent control on the same page or on a different step in a multi-step process passes the SC. "

DavidM: The SC doesn't require that the control is visible. It is the information is needed...

DavidF: I think it was last meeting on steps, multi step, process, I think we need to resolve it if we haven't already.

<Zakim> mbgower, you wanted to say Information needed to identify user interface components is visible without requiring pointer hover or keyboard focus.

<AWK> "without interaction" ?

MikeG: I previously suggested this. The phrasing of Identifying , is what we have in non text contrast as well.

<Fazio_> That ignores user's freedom of choice

MikeG: We were looking at what were needed to continue. If the control is secondary and not displaying the entire time, then perhaps we look at this in the SC.

AlastairC: Recognize how to operate.

<david-macdonald> I can go with that

<JF> +1 to Mgower's proposal

MikeG: Identifying , makes sure it is visible.

<Rachael> +1 to adding that exception back in

<david-macdonald> +1 to that exception

SarahH: We originally talked to exception of a setting , i.e. controls in zoom always visible or not. We lost that as an exception in what we are talking to at moment.

AWK: Present and visible without requiring interaction

AlastairC: I've added that to the Google Doc.

<kirkwood> identify

JF: Recognize how to operate , individual users may not know how to operate. Concerned on that text.

<alastairc> https://docs.google.com/document/d/1v9VN9JN7fWIv1fIlBNXRhibMnRavn0M2Bx6AohtZ_jc/edit#

JF: Locate may be a better word.

AlastairC: Information needed to identify user interface components is visible without interaction.

<Rachael> or a mechanism is available to make the information persistently visible.

Rachael: We did lose the mechanism to make it consistently visible text.

DavidM: We may need to fall back to a visible entry point, i.e. a menu and interacting with it. Clicking and pressing enter key. Keyboard focus and pointer hover was a subset of interaction. Hover and pointer was the common thread from COGA .

David, hope I typed all of that in correctly for you.

<Zakim> mbgower, you wanted to say problem with 'without interaction'

DavidM: Possibly another exception bullet point.

<Rachael> +1 to narrowing it to hover and focus

MikeG: Same concerns as David. Interaction is broad. COGA examples talk to pointer hover.

If you remove keyboard focus, 2.1.1. SC is present. Main SC focus of this SC is by pointer.

AlastairC: Problems arise when removing keyboard focus on hover.

AWK: Can we confirm that we are talking to this on all controls ?

AlastairC: all controls, and carving out exceptions.

AWK: All controls need to be visible , at all times? Except exceptions ?

MikeG: They need to be visible without pointer hover.

DavidM: Hamburger menu, once clicked or enter , must be visible. Rather than just hover.

<Fazio_> coga point was to be able to land on page and immediately understand where you are what you can do and how to do it

<Caryn-Pagel> Or even just basic video controls that typically hide while the video is playing

AWK: Video and social media icon. Expands to showcase social channels. Items underneath are hidden. Is it different from focus it or hover it? Focus is needed to click on it.

AlastairC: On hover thing that is needed is menu, which then display other items underneath it. Another example, edit and other controls. Nothing present until hover, that would fail.

AWK: On social media controls, on however, would that pass or fail?

DavidM: and AlastairC: Pass, as it showcases the available controls.

<Fazio_> hp5?

<Fazio_> h5p

JF: Controls are on the video player.

Concept is part of player and not video itself.

DavidF: This came from COGA usable document. What is available to them on landing on the page?

What is actionable and not worrying about how do I do this.

DavidM: I defer my comment.

SarahH: Design principle of progressive disclosure would be worth reviewing.
... It limits to make it intentional and allow users to make choices.

<Fazio_> or create a media control parent that contracts to reveal controls

I need to drop, thank you.

<Sukriti> I'll do it

<alastairc> scribe:sarahhorton_

<Zakim> AWK, you wanted to ask what would make a set of social media controls with a video to fail

AK: Social media controls, only way to button is hover over portion of screen, that fails. But video with icon persistently present passes.

<Fazio_> +1

DM: If nothing there, hover, something shows up, that's the concern

<Zakim> mbgower, you wanted to respond to andrew :)

AC: Shows YouTube videos, do those icons fail?

MG: Page with video embedded, only way controls display is on hover or click. Doesn't solve problem of needing to interact with video container

<Fazio_> there not controls

<Fazio_> they're shortcuts

AC: Gap?

<Fazio_> that wasn't the player

MG: Reality, subcomponents could get messy if all controls have to be there

<Fazio_> my point exactly

AC: Functionality also available clicking through to video
... would pass then because of multi-step process

CP: Questions about controls on videos, seems like taking away from experience

DF: Shortcut, click on video, brings up player with controls

<Fazio_> controls aren't necessarily all buttons

SC: Tedious process to get to alternates

DM: Click on it, only an issue if hover is required to get there

<Zakim> AWK, you wanted to ask a question about first exception - seems like we need the opposite

AK: First exception confusing, "visual presentation" is essential
... Lack of visual presentation is essential

DM: Creating this exception for a lot of SCs

<Rachael> suggest" Hiding the control is essential for functionality

<mbgower> I agree. No point to that exception with current wording

AK: There is exception where you can require pointer hover if it's essential to be handled in that way

RM: Video is good example, hiding controls while watching videos

AK: Interactive exercise, click on aorta, show video, quiz, essential that it's hidden

<Rachael> online escape room would be another

AC: Definition of "essential" makes the video less likely

DM: Video scenario, once you do it once you learn it, convention, could carve out exception

<Fazio_> dementia

AC: "Information needed" know where controls are, video could be the information

<Fazio_> alzheimers

<Fazio_> so no

<Zakim> mbgower, you wanted to say there is no exception needed for video. it works fine with the current SC

GN: Important user recognized video, understands needs to interact with video player, essential when it's hidden is also recognizable

MG: Video is visible, video is the menu icon, challenge is distinguishing between video/image
... controls appear when they activate the video

<david-macdonald> Question to David Fazio, do you know of an issue with controls on videps?

<Fazio_> +1 john

JF: Video player, what you see is the video player with content in it
... focus on embedded player in page, controls may be native in the browser

<kirkwood> +1 to JF

<Fazio_> no

<david-macdonald> https://www.w3schools.com/html/tryit.asp?filename=tryhtml5_video the HTNML 5 video player has controls available as a option...

MG: YouTube, timestamp on bottom, first one has no visual indication, is timestamp sufficient?
... text input clearly established, video container not sure there is

JF: Author may/may not have ability to make controls persistently visible

DF: Assuming people will recognize and know what to do, why we created user need, people who don't recognize thing, dementia, Alzheimers, can happen with trivial things
... this is why we are pushing this SC
... controls must be readily available, visible, operable
... If controls appear, may not remember them

AC: Controls appearing on hover, for this requirement will require persistent controls or mechanism
... persistent may not be desirable for all users
... putting on user need to know where to find option, not practical
... consider video icon or media as the means to understand there are controls available, then it's visible

AC reviews examples in Essential Controls Examples

JF: Let's call them media player controls, applies to video, audio, some other embedded thing

<Fazio_> +1 john

JF: lines we need to define, is it author-supplied? natively supplied? May not have ability to conform to SC

AC shows YouTube video

AC: Is the video playing enough to know there are controls available

<Fazio_> for dementia it is a no

<Fazio_> Down syndrome, sometimes yes sometimes no

<kirkwood> John has a good point here

JF: Matters because of who has control over what displays

DM: May expand later, get people thinking about this, make exception for media?

<DavidASx> Able player keeps controls visible all the time unless full screen

JF: Data visualization, interactive control when you start interacting

<JF> "author-supplied" controls

<JF> IMPORTANT: https://html.spec.whatwg.org/multipage/media.html#user-interface

DM: "Information needed" provides guidance, allows for conventions
... squishy, there to allow more flexibility
... at some point, primary and secondary functions

<alastairc> sarah: The design principles are helpful, we're talking about visibility.

<alastairc> ... that's the underlying principle. As a designer it's on you to think about whether a word at the top is enough to indicate it's a menu

<alastairc> ... design evolves as new things become convention. I would agree the video content is a control in that case, it is activating the visibility of additional controls.

<JF> The content IS NOT the control, it's the content

<Fazio_> This was intended for the population that cognitively don't recognize convention

<alastairc> ... it's only because it has become a convention. As a designer I would want to add something to make them persistent.However, for writing the SC, I'd be hesitant to put those in the SC. Focus on what we're trying to accomplish, not worry about the loopholes

JF: pasted link to video player, saying if author does not provide controls, user agent provides them
... need to underscore "author-supplied"

AC: How do we scope what's in and out

JF: Suggest that user-agent supplied controls are out of scope

AC sharing document

AC: "Information needed to identify user interface components is visible without requiring pointer hover or keyboard focus, or a mechanism is available to make the information persistently visible. "

<JF> Proposal: Information needed to identify >>author-provided<< user interface components is visible without requiring pointer hover or keyboard focus, or a mechanism is available to make the information persistently visible.

GN: Not content with author-provided, authors who try to improve are disadvantaged, would drop that exception

<Zakim> Chuck, you wanted to ask "...and not modified by the author", same as non text contrast

GN: when you have player, player plays, listen, watch, you have context menu to interact or have shortcut, videos are covered with the original wording
... accessing interaction is one step away, controls are available because you have a player in front of you

<JF> Mandating visual cues is a slippery slope

GN: it moves, there's a play button, it's distinguishable

AC: "Information needed to identify user interface components is visible without requiring pointer hover or keyboard focus"

AK: ABout equivalent control, alternative way to word SC to eliminate need

<AWK> All functionality of the content can be operated by user interface components without requiring pointer hover or keyboard focus to make the user interface components visible.

<Ryladog> +1 to AWK

<AWK> All functionality of the content can be operated by user interface components without requiring pointer hover or keyboard focus to first make the user interface components visible.

<alastairc> q/

DM: Does work, however hard to parse, first iteration was clearer

<Zakim> mbgower, you wanted to say preamble seems redundant

<AWK> All functionality of the content can be operated without requiring pointer hover or keyboard focus to first make the user interface components visible.

<Ryladog> +1 to MG

<JF> proposal: The appearance of the control is determined by the user agent and not modified by the author /The discoverability of the control is determined by the user agent and not modified by the author

<AWK> All functionality of the content can be identified without requiring pointer hover or keyboard focus to first make the user interface components visible.

MG: Warning that wording with keyboard focus, previous was identify them and this language has operate them

<GN015> *1 to Mike

JF: Wordsmithing, not appearance it's discoverability

<AWK> Mike, I agree with what you said, so adjusted the wording to change operated to identified ^^^

<mbgower> yep, visibility is friendly to me

AC: Come a long way from a couple weeks ago, probably works, concerned about some language, "information needed", what constitutes meeting that
... drawing line is crux of problem

<mbgower> +1 to making current version

<Rachael> +1

<DavidASx> +1

<juliette_mcshane> +1

+1 with some attention to language of exceptions

<Chuck> +1 to updating this proposed sc to the content within the document.

<JF> +1

<Sukriti> +1

<david-macdonald> +1

<Rachael> Thank you so much to the subgroup's who worked on this!

This is scribe.perl Revision of Date 
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: Chuck_, Rachael, Laura, alastairc, stevelee, Fazio, kirkwood, Caryn-Pagel, sarahhorton, JakeAbma_, Matt, Orr, MarcJohlic, MelanieP, bruce_bailey, mbgower, MichaelC, Wilco, Katie_Haritos-Shea, juliette_mcshane, JustineP, david-macdonald, (sorry, to, be, late, held, up, by, meeting), GN, sajkaj, Chuck, Detlev, Raf, Francis_Storr, Sukriti, ChrisLoiselle, morr, Nicaise, JF, Glenda, AWK, StefanS, JakeAbma, DavidASx
Present: Chuck_ Rachael Laura alastairc stevelee Fazio kirkwood Caryn-Pagel sarahhorton JakeAbma_ Matt Orr MarcJohlic MelanieP bruce_bailey mbgower MichaelC Wilco Katie_Haritos-Shea juliette_mcshane JustineP david-macdonald (sorry to be late held up by meeting) GN sajkaj Chuck Detlev Raf Francis_Storr Sukriti ChrisLoiselle morr Nicaise JF Glenda AWK StefanS JakeAbma DavidASx morr4 GN015
Regrets: JustineP
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Found Scribe: ChrisLoiselle_
Inferring ScribeNick: ChrisLoiselle_
Found Scribe: sarahhorton_
Inferring ScribeNick: sarahhorton_
Scribes: ChrisLoiselle, ChrisLoiselle_, sarahhorton_
ScribeNicks: ChrisLoiselle, ChrisLoiselle_, sarahhorton_

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


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