<alastairc> meeting: AG teleconference
<LoriO> preseent+
<alastairc> scribe: LoriO
<Chuck> agena?
<Chuck> ...this is an example of a previous person continuing comments
<Chuck> Thank you LoriO!
no announcements
let us know if you are coming to tpac
<Rachael> W3C TPAC Interest https://www.w3.org/2002/09/wbs/35422/tpac_2023_interest/
<AWK> +AWK
handing to Rachael
<Rachael> https://www.w3.org/2002/09/wbs/35422/working_draft_23/
Rachael: last survey before working draft, open till Monday
3 questions on the survey, merged our conversations, link to full draft
scribe: editors draft
<Rachael> https://www.w3.org/WAI/GL/wiki/Maturity_Labeling_Process
3rd question need to publish from editors draft, labeling our content as to level, placeholder and exploratory not going in,
<Luis> Just a heads up that the surveys are showing "Not Allowed" for Silver Community group folk
scribe: need to put out placeholder and exploratory needs to go out, can we move the whole thing or parts that should stay in
<Luis> Thanks
is it members only, it wasnot supposed to be
alastairc: fill out the survey
Wilco: please add a diff
Rachael: I'll try to add a diff
<Chuck> We love your effort Lorio!
alastairc: that's all of the WCAG 3
alastairc: moving on to WCAG 2.2, three questions that are fairly important,
<alastairc> https://github.com/w3c/wcag/pull/3146
alastairc: question 1 screenshot of question 1, there were a few comments, I've added links requested
Rachael: not very stable, there are spelling mistakes, I'll try to do a spellcheck
alastairc: most people positive
<alastairc> draft RESOLUTION: Accept PR 3146
<mikeGower> +1
<bruce_bailey_> +1
<Rachael> +1
<joweismantel> +1
<ShawnT> +1
<kirkwood> +1
+1
<Poornima> +1
<Francis_Storr> +1
<Makoto> +1
<mgifford> +1
alastairc: please vote
<ChrisLoiselle> +1
RESOLUTION: Accept PR 3146
<alyssa_priddy> +1
alastairc: question 1 is accepted with changes
<alastairc> Content opened by the user can obscure focusable items. If the user can close the opened content without moving keyboard focus (for example, by dismissing with Esc), then it is not considered to obscure items underneath.
alastairs: question 2 focus not obscured, suggestion to add two notes, discussion on the list
<mgifford> Possibly a bit simpler would be: "Content opened by the user can obscure focusable items. If the user can close the opened content without moving keyboard focus then it is not considered to obscure items underneath. An accessible example, is one where the opened content could be dismissed using the escape Esc key."
alastairc: is this understandable, please comment, can we do something in a note?
<Chuck> +1 with the challenge of trying to add to normative language
mgifford: difficult to get into normative language, so many nuances, understanding is good, hard to describe correctly
<mbgower> Alastair, you should put the note in the PR on screen. What you pasted is not the current note
Ryladog: hard to do this all together
Wilco: should be in normative text
<mgifford> LoriO: I just want the wording to be simpler. Shorter sentences. Something web developers can more easily grok.
gno15: if user opens dialog, focus goes there, not behind, if the user steps away and comes back won't be able to tell where the focus is
alstairc: linkedIn, you can open a window that covers the page content, you can tab behind, instances where not modal
gno15: user may have left, and comes back, where is focus
alastairc: in response to wilco, WCAG dos not handle a page with different areas changing,
greggvan: does text make it clearer that makes it normative, this text, (shared screen)
jon_avila: initially confused, initial state closed seems to contradict, valid issue, normative doesn't say if user opened it or not, need to update initial state, very confusing, new text is much clearer
mgifford: long sentances, need short sentances, easier to read and understand, analyzed content and second sentance still to long and raises reading level
<jon_avila> If something like a mega menu would closes after you tab out of it then it should pass this as it would not be obscuring other things outside the menu when they receive focus.
<alastairc> jon_avila - correct, that's an easy example
poornima: concerned with 2nd, what about drawers?
<mgifford> alistairc: totally get the struggle with this. I'm don't a wordsmith, and appreciate that others have greater skills for juggling the if/then challenges you posed..
greggvan: clarify by different wording
mbgower: struggling, you can change focus with non modal dialogs, how can we reword to be more understandable, there are components that have two focuses, gives an example,
<mgifford> LoriO: Not sure if it is possible to include my recommendation to use the https://hemingwayapp.com to review new SC for complexity. I don't care about the tool, but there should be some tool to see that we push ourselves to simplify the language.
<mbgower> Yes!
<Poornima> I think as long as the content opened can be closed with keyboard (eg. Close, Minimize, ESC) might hold good to address different types of components
alastairc: summarizes note1 and note2
<Zakim> alastairc, you wanted to summarise
<mbgower> Where content disclosed by the <em>user</em> can obscure other content, if the user can reveal the item with focus without moving keyboard focus (for example, by dismissing with Esc), such disclosed content is not considered to fully obscure the item receiving focus.
<Wilco> +1 to explaining this as author content
mbgower: text that's in PR readability will go down, can change to pivot to alastair's comment,
<Wilco> non-author content, that is
alastairc: mike is trying to come back with simpler text
<mbgower> Where content disclosed by the <em>user</em> can obscure other content, if the user can reveal the item with focus without moving keyboard focus (for example, by dismissing with Esc), such disclosed content is not considered to hidden by author-created content.
wilco: comments on note 2
alastairc: adds mbgower's text above
mbgower: will try to blend both versions of note 2
<GN015> I feel a "be" is missing in the suggested text above. "not considered to be hidden"
<alastairc> Updated suggestion for the note: This criterion applies to content that appears in addition to the triggering component itself. Skip links and other hidden component that is made visible on keyboard focus is not covered by the SC, unless <em>additional</em> content beyond the trigger becomes visible.
alastairc: question 3, not 2.2 directly, reads MikeG's comment, there is a note at the bottom but could move it up, wilco suggested an update, adding to 2.2 and 2.1,
alastairc; reads text above,
<Chuck> Lorio: You added the 's', thank you.
<Chuck> back to you LoriO
<alastairc> Updated: This criterion applies to content that appears in addition to the triggering component itself. Skip links and other hidden components that are made visible on keyboard focus is not covered by this criterion, unless <em>additional</em> content beyond the trigger becomes visible.
<Luis> I think that should also be "are not covered"
alastairc: updating the text, wilco is this okay? he replied yep, this is the suggested
luis: corrects text
<alastairc> draft RESOLUTION: Accept PR 3130 as ammended
<bruce_bailey_> +1 but can we accept that there might be more very minor editorial ?
<Poornima> +1
<ShawnT> +1
<joweismantel> +1
<Rachael> +1
<bruce_bailey_> Just +1 then !
jon_avila: concerned introducing something new, rather than additional content, whole thing the trigger? introduces something we weren't expecting?
alastiarc: agree skip links not a problem, wording more broad? not opposed to moving it
<Zakim> bruce_bailey_, you wanted to say would like to see Skip Links as an example of something in SC
greggvan: it's an exception add an example, no note that says this is not covered
bruce_bailey_: shares gregV's concern that note is an exception
awk: how do we know this is a big problem
alastairc: trying to make it more understandable
awk: changing normative doc is a slippery slope,
<bruce_bailey_> Might the NOTE offer that Skip Links -- as typically implemented -- are an example of Dismissible (exception)?
alastairc: is this normative text? I do not believe it is, voices why, note has been there a long time, move note up?
@greggV +1
<alastairc> Does anyone remember the original logic for this note?
<Zakim> mbgower, you wanted to say the note already exists
greggvan: don't add lots of notes, skip links should not be covered, making it obvious
mbgower: not altering the note, just changing the position of the note, skip links fail normative text, the normative text, just moving it
<Zakim> GreggVan, you wanted to say simply "the fact that a note has been around a long time -- does not make it legal just because no one noticed it was a bad note before)
alastairc: there were suggested updates, two separate ?s, does anyone remember why two notes?
<jon_avila> When we say move up - we are speaking about moving it from understanding doc to success criterion, right?
<GN015> As skip are no longer state of the art and can cause a lot of issues, should we add at least a recommensation into the understanding document to use regions and landmarks instead of skip links?
<mbgower> Different topic!
greggvan: just because its been around doesn't make it right, should carefully revise it
alastairc: is it trying to make an exception, I don't think so, let's do a poll
<Luis> I can scribe
<alastairc> scribe: Luis
<alastairc> Poll: Should we move the note from the understanding document to underneath the SC text? +1 for yes
<Zakim> GreggVan, you wanted to suggest "since xxxx is just a change in the target appearance and not new content, it is not prohibited by this SC"
+1
<Wilco> -.5
<GreggVan> +1
<jon_avila> +.5
<Ryladog> +1
<LoriO> +1
<Rachael> 0
<JenStrickland> +.5
<bruce_bailey_> +1 for moving from Understanding to SC
<dan_bjorge> +.5
<mbgower> +1
<AWK> -.5 don't think it is a good idea
<mgifford> I just don't have an opinion on this.
wilco: Can't put everything in notes into the normative section. Maybe make it more prominent in the Understanding document.
<jon_avila> It seems safer to keep in the understanding document just in case it creates some loophole.
JenStrickland: agreed with wilco, it's a slippery slope. Folks want to do the right thing, but just don't understand.
AWK: There's the possibility of confusion; we can only update it when we update the standard. More practical to train people to look for clarification in the Understanding documents.
<Zakim> mbgower, you wanted to say that notes that illuminate the normative text make sense in that context and should be viewable there
<Zakim> GreggVan, you wanted to say - we add a note when something common is not understood or is often misunderstood, or where the understanding is not at all clear from the SC language
mbgower: This is the last time we're going to be changing WCAG 2.x; it's one note, not a slippery slope.
GreggVan: We add a note when something is common or the understanding isn't clear (even to our team). I think this is a good case for moving it and also put into a proper form.
<bruce_bailey_> +1 to GV that note meets bar for promotion from Understanding to SC
<Poornima> +1 for the fact that 'adding exceptions on specific type of elements help to relate and identify ways to satisfy the sc'
alastairc: This is kind of even. I'm swayed since this is hopefully/likely the last edit. I think we'll resolve to move it if we can agree on the text.
<alastairc> This criterion applies to content that appears in addition to the triggering component itself. Skip links and other hidden components that are made visible on keyboard focus are not covered by this criterion, unless <em>additional</em> content beyond the trigger becomes visible.
GreggVan: Maybe changing the appearance of the target, it'd be fine
<bruce_bailey_> i like it , but is "skip links" too close to jargon ?
alastairc: What other loopholes could this language open up?
GreggVan: I think the long
version covers it. It doesn't say "since" in it, you want
something that says "since this is true, that's why it's
accepted"
... "excepted" not "accepted"
<alastairc> This criterion applies to content that appears in addition to the triggering component itself. Since skip links and other hidden components that are made visible on keyboard focus do not present additional content, they are not covered by this criterion.
bruce_bailey: "skip link" isn't a defined term in the glossary. Worried this being the only use of it in WCAG
<alastairc> draft RESOLUTION: Update the note and move to below the SC text
<AWK> "visually-hidden page-navigation link"?
<Zakim> bruce_bailey_, you wanted to ask if we adding skip link in glossary ?
<bruce_bailey_> We do not even mention Skip Links in Bypass Blocks
<Wilco> -.5
GreggVan: I think we could link to the understanding doc to explain it. It's not normative, so shouldn't be in the appendix.
<bruce_bailey_> We could add note to SC that Skip links are a common example of how to meet Bypass Blocks
alastairc: The only further change might be to link "skip links" to...something that isn't a definition. How do people feel about it now?
+1 haha to wilco
<bruce_bailey_> https://w3c.github.io/wcag/guidelines/22/#bypass-blocks
alastairc: Maybe make "skip links" a "such as..."
LoriO: want to make sure people know what skip links are. Don't forget we'll have people who have never done a lot of this work before. Don't forget the beginners.
<bruce_bailey_> +1 to LoriO comment not to forget first time readers
<AWK> Since hidden components that are made visible on keyboard focus, such as links used to skip to another part of a page, do not present additional content they are not covered by this criterion.
+1 to LoriO; thinking of beginners
<mgifford> There are also folks who think that Skip Links aren't needed because we've introduced ARIA regions. This isn't the case, but it is a conception that is out there.
<dan_bjorge> anchor icons used to indicate anchor link locations next to headers is another example I can think of
GreggVan: There are more places than just skip links. It would be convenient to have a control to pops up for navigation, etc. I don't think this'll be the only time this comes up.
<Zakim> alastairc, you wanted to suggest scoping to links or controls.
<jon_avila> Yes, Jira has table header sort buttons that appear on focus as well as the heading anchors for copying.
<bruce_bailey_> q0
alastairc: Was thinking that since links like skip links don't present additional content, they're covered. Maybe "either links or controls"
<AWK> Since hidden controls that are made visible on keyboard focus, such as links used to skip to another part of a page, do not present additional content they are not covered by this criterion.
<GreggVan> +1 to alistair and AWK
AWK: That's why we're saying "such as" other conditions may apply.
<alastairc> q/
<Zakim> mbgower, you wanted to say we do have draft PR that adds and objective
mbgower: re: LoriO's comment. There is a balance between clarity and precision. We do have a draft PR that adds an "objective" which is a simple short statement that explains the objective and could fill that gap for beginners. Do we need to have that in place to publish or can we add it later?
<bruce_bailey_> please change last "they" to "hidden content"
alastairc: That's informative, so the task force will adjust those
<bruce_bailey_> Since hidden controls that are made visible on keyboard focus, such as links used to skip to another part of a page, do not present additional content hidden controls are not covered by this criterion.
bruce_bailey: the "they" is ambiguous what it is referring to
<mgifford> GreggVan: Your discussion of additional keyboard options, also reminded me of IDRC's Preference Editor. Also the UI Options Plus (UIO+) Chrome extension https://chrome.google.com/webstore/detail/ui-options-plus-uio%2B/okenndailhmikjjfcnmolpaefecbpaek
<mbgower> I emphasized that language precision necessary in a standards document is in almost direct opposition to simplicity and an easier reading level
<bruce_bailey_> Since hidden controls that are made visible on keyboard focus (such as links used to skip to another part of a page) do not present additional content, hidden controls are not covered by this criterion.
<mgifford> It provides an interesting model for Skip Links tied to the headings, creating a visual Table of Contents.
<dan_bjorge> I think the version Alastair had in IRC at a timestamp 15 minutes ago was more clear than this version
<bruce_bailey_> Never mind, they is okay -- but keep parenthesis i think
<AWK> Since hidden components that are made visible on keyboard focus, such as links used to skip to another part of a page, do not present additional content they are not covered by this criterion.
<bruce_bailey_> Alastairs version, but use parenthesis
+1 to "they" and parenthetical
<AWK> Since hidden components that are made visible on keyboard focus (such as links used to skip to another part of a page) do not present additional content they are not covered by this criterion.
<bruce_bailey_> Ah! -- comma before they
<bruce_bailey_> Since hidden components that are made visible on keyboard focus (such as links used to skip to another part of a page) do not present additional content, they are not covered by this criterion.
RESOLUTION: Update the note and move to below the SC text
<bruce_bailey_> +1
+1
<mbgower> Content opened by the user may obscure the item receiving focus. If the user can reveal the item that has received focus, such content opened by the user is not considered to be author-created content.
<dan_bjorge> Change it to "opened or repositioned" and it can replace note 1, too
<mbgower> Content opened by the user may obscure the item receiving focus. If the user can reveal the focused item without advancing the keyboard focus, such content opened by the user is not considered to be entirely hidden due to author-created content.
mbgower: The second is wordier, but covers more
<mgifford> Sorry, I have to jump off. Thanks everyone.
mbgower: I think this covers the concerns wilco had. We'll have to explain in the Understanding document anyway.
<bruce_bailey_> advancing the keyboard focus --> moving the keyboard focus ?
alastairc: I have 4 versions on the screen now. The original, the version suggested in email, and mbgower's two suggestions.
mbgower: I think the second of mine is better. We need to have some constraint on how the author constructs this.
alastairc: Any suggestions for updates?
bruce_bailey: Advancing seems "directional" maybe "moving" instead. And drop "considered"
<alastairc> q/
alastairc: Not sure. The "considered" gives us the "why"
<bruce_bailey_> feel like hand waving
<bruce_bailey_> i am okay with it
<mbgower> yep, working on it
GN: Why do we suddenly talk about content being hidden instead of the control
mbgower: Working on it
<LoriO> what about replacing content with component?
<mbgower> Content opened by the user may obscure the item receiving focus. If the user can reveal the focused item without advancing the keyboard focus, the item with focus is not considered hidden due to author-created content.
alastairc: We have two things. The content opened by the user and focusable items that may be underneath that content.
LoriO: Suggested replacing "content" with "component" since it sets a good scope for developers
<mbgower> Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered hidden due to author-created content.
<jon_avila> The pop up could contain non-component items.
alastairc: If you have components within components, how do handle that? So we go with content.
mbgower: Incorporated feedback
<Rachael> Content opened by the user that obscures the item receiving focus and can reveal the focused item without advancing the keyboard focus is not considered to be entirely hidden due to author-created content.
Rachael: can we combine the first sentence?
alastairc: It's shorter, but seems less clear
<Rachael> fair enough to both points
<alastairc> ack \
<mbgower> Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered hidden due to author-created content.
mbgower: I think using
"component" is actually better because it's called "component"
in the normative part
... I changed from "moving to advancing" because it allows us
to talk about the difference between putting the focus on a
different non-modal vs "pressing tab key"
<alastairc> draft RESOLUTION: Accept PR #3083, Note 2 is updated by the text above
alastairc: It's just on focus; not obscured and updates SC text those two notes.
mbgower: I want to make sure folks are clear that the first note has been altered as well. It did seem to scan better without updating the meaning. Just wanted to make sure it was clear.
<Zakim> dan_bjorge, you wanted to agree with jon
jon_avila: I think the two notes conflict. Being closed is the initial state for some things, but not all things the user can open.
<bruce_bailey_> +1 and edit is another use of "considered" so that part consistent with previous SC note we discussed.
<Zakim> mbgower, you wanted to say
dan_bjorge: One talks about initial state vs closeable. It feels off that they're explaining the same understanding. I think they should be consistent.
mbgower: What do you mean by "one is covering moveable vs open content?"
jon_avila: Not sure where the difference is. When I'm testing is it closed by default, that's all I need to worry about.
dan_bjorge: Maybe combine into one note "for content that can be closed or repositioned"
alastairc: The first is if the user can move it within the viewport; the second is where there are predetermined places. Sometimes both can apply.
poornima: For the second note,
the caution is whether it's the content opened by the user or
author opening content. e.g. cookie pop ups.
... modals, dialogs or other things opened by user are similar
to the hover/focus SC
... I don't think it's clear between author-created or user
opened content. Do we need to mention "content opened by user"
because it's pretty straightforward. If it's opened by user,
there needs to be a mechanism to close or something.
<Zakim> mbgower, you wanted to say is the problem that you think open is repositioning?
mbgower: These are different use
cases. If I can move something, I can obscure anything.
... the author can't be responsible for that
... for the second one, we're talking about something that
opens/closes in a fixed position. There is a lot of content in
Understanding supporting the Note.
<Zakim> bruce_bailey_, you wanted to ask about "page in initial state"?
bruce_bailey: They feel very different to me.
alastairc: To summarize. We have two proposed notes that I think are different scenarios. We could make it a little more clear. And there are more scenarios covered in the Understanding document. The reason to pull these up is because they're commonly confused.
<mbgower> Alastair, can you please generate a rawgit version of the Understanding doc so people can review?
alastairc: any concerns with having them as Notes?
Wilco: Is the question "do we want notes at all?"
<Chuck> +1 to notes
<bruce_bailey_> +1 for notes to this effect
<mbgower> +1 to notes
alastairc: Do we want notes saying "if the user can move things, it's their problem. If they can open something that gets in the way and close it, it's not considered to be obscured"
wilco: then "yes"
+1 to notes
for the record, I love notes
<alastairc> draft RESOLUTION: Accept PR #3083, Note 2 is updated by the text above
<mbgower> +1
<joweismantel> +1
<ShawnT> +1
<Rachael> +1
<bruce_bailey_> +1
<Wilco> 0
<Makoto> +1
+1
<JenStrickland> +1
<dan_bjorge> +.5
<Ryladog> +1
<jon_avila> +.5
<Poornima> +.5
<LoriO> -1
LoriO: When you say "content opened by the user can obscure focus" as soon as you click on something that's where your focus is.
alastairc: If you open messages in LinkedIn, you can open it with keyboard, then you can tab around the interface and everything is behind your message. So the messages can obscure other focusable items.
LoriO: I'm talking about the mechanics.
<mbgower> I don't understand the question
LoriO is talking about the focus indicator
alastairc: You can keep tabbing and go behind the pop over content.
<Zakim> mbgower, you wanted to say the article linked in the resources provides some examples
RESOLUTION: Accept PR #3083, Note 2 is updated by the text above
mbgower: LoriO, alastairc put the rawgit link, if you follow it, it has resources to a Knowbility article where they talk about slide out navigation and methods of the focus being obscured
<jon_avila> thank you
alastairc: Thank you everyone. The CFC to PR will be a little complicated, but that'll be coming shortly now that this is out of the way. Have a good week. Make sure to present+
mbgower: If I make more commits, will those get reflected in rawgit
alastairc: Probably not,, it needs to use the branch name
mbgower: Can you paste it into the PR conversation so folks can get to it?
alastairc: Yes
This is scribe.perl Revision VERSION of 2020-12-31 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/last survey/Rachael: last survey/ Succeeded: s/:alastairc fill out the survey/alastairc: fill out the survey/ Succeeded: s/:Wico please add a diff/Wilco: please add a diff/ Succeeded: s/:bradley I'll try to add a diff/Rachael: I'll try to add a diff/ Succeeded: s/(exception)./(exception)?/ Succeeded: s/shares gregV's exception/shares gregV's concern that note is an exception/ Default Present: ChrisLoiselle, GreggVan, shadi, Rachael, alastairc, ShawnT, Lauriat, Jennie, Wilco, bruce_bailey_, Francis_Storr, J_Mullen, wendyreid, Makoto, jon_avila, mgarrish, AWK, sarahhorton, joweismantel, Luis, kirkwood, Poornima, JustineP, Katie_Haritos-Shea, mbgower, JenStrickland, dan_bjorge, .5, mgifford, GN Present: ChrisLoiselle, GreggVan, shadi, Rachael, alastairc, ShawnT, Lauriat, Jennie, Wilco, bruce_bailey_, Francis_Storr, J_Mullen, wendyreid, Makoto, jon_avila, mgarrish, AWK, sarahhorton, joweismantel, Luis, kirkwood, Poornima, JustineP, Katie_Haritos-Shea, mbgower, JenStrickland, dan_bjorge, .5, mgifford, GN, GN015 Regrets: (sorry, urgent deadline) Found Scribe: LoriO Inferring ScribeNick: LoriO Found Scribe: Luis Inferring ScribeNick: Luis Scribes: LoriO, Luis ScribeNicks: LoriO, Luis 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]