Meeting minutes
zakim , take up next
Announcements
MaryJo: PRs are incorporated. Looking for volunteers on open issues and making PRs or proposals for answers to issues.
MaryJo: Notes help when reviewing. There are a number of open issues.
MaryJo: August 1st will not be meeting as MaryJo is out.
No meeting that week as she is traveling.
Document for proposals is in Google Docs
<maryjom> Here’s the link to the Google doc where you can propose substantive changes and issue responses: https://
Headings for issue number is the logic I've been following.
Github is also an avenue, thanks Bruce.
<bruce_bailey> My attempt blew up w3c/
BruceB: I wanted to double check on Mitch's work. Are those still up for grabs?
MaryJo: Yes, they are.
MaryJo: Proposals are welcome.
<bruce_bailey> thanks to mitch, nice and granular
BruceB: Thanks to Mitch.
BruceB: I would like us to meet on 1st of August if we could to talk through items if possible.
MaryJo: That is fine, however facilitation needs to be done by someone else than MaryJo.
DanielM: I can help. Chuck also states the same.
<Zakim> bruce_bailey, you wanted to double check that mitch's items up for grab?
MaryJo: We may have extra meetings depending on remaining open issues .
Public comments
Issue 437 , page title
<maryjom> Issue 437 on SC 2.4.2 Page Titled. Link: w3c/
<bruce_bailey> my draft proposed response
<bruce_bailey> w3c/
<bruce_bailey> Thank you @stevefaulkner for the feedback. The TF discussed and we have consensus that 2013 approach is appropriate and sufficient. Please see 2.4.2 Page Titled in the editor's draft.
MaryJo: Pretty active discussion. Wasn't clear that we applying to only software application as a whole and not to individual views.
MaryJo: I shared my thoughts on thread. Steve brought up original question on it not being clear. I started something on Google Doc on best practice.
MaryJo: Reviewed Mac and applications and window titles on overlay or other like type examples.
Here's Google doc that talks to this topic.
If you scroll up, you'll see notes we already have.
Proposal is to add something about best practice.
MaryJo: Referenced window being Firefox Browser being the window title and the fact that doesn't clarify what page means.
<bruce_bailey> +1 for note
BruceB: two options labeled as 1.
MaryJo: One would go into issue and one would be response.
<loicmn> +1 for note
MaryJo: Mobile task force is looking at this regarding views within mobile app.
<bruce_bailey> i concur that raising to requirement is a risk
Proposal 1: Note indicating “best practice”
One possible addition could be a note that is similar to what is added to “sets of” criteria: Although not required by this success criterion, ensuring that individual windows or screens have a title that describes the topic or purpose addresses the user needs identified in the Intent section for this success criterion, and is generally considered best practice.
MaryJo: We may add a note. I added a comment in the issue.
BruceB: Will you point Steve to Google Doc? Or GitHub issue?
MaryJo: Do you think we need to work on it a bit longer?
BruceB: Ok to copy into issue.
MaryJo: to post into issue the proposal she had in Google Doc.
Other open issues
Issue 408 - Typo in 3.3.8 Accessible Authentication, Note 4
<maryjom> w3c/
<maryjom> PR: https://
MaryJo: I made PR on what I thought problem was, https://
… instead of when , use or was also something I wanted to review.
MaryJo: Shares screen talks to line 1041 on pull 442 and phrasing of terms.
MaryJo: I believe we meant when and not or per what we covered originally.
<maryjom> POLL: Which verbiage should we use instead of “on when”? 1) Replace with “or” or 2) remove “or” to read “when”?
<maryjom> POLL: Which verbiage should we use instead of “on when”? 1) Replace with “or” or 2) remove “on” to read “when”?
<Sam> 2
2
<loicmn> 2
<FernandaBonnin> 2
<bruce_bailey> 2
<Bryan_Trogdon> 2
<olivia> 2
<ShawnT> 2
RESOLUTION: Incorporate PR 442 as-is to remove “on”.
MaryJo: talks to issues opened by Mitch on 3.2.6 , issue 428
Issue 428 - 3.2.6 Consistent Help: does it need to be added in 'problematic for closed'?
<maryjom> w3c/
MaryJo: Reads through Mitch's comments on issue 428.
<maryjom> Poll: Should we add 3.2.6 Consistent Help verbiage similar to other "sets of software" to SC Problematic for Closed 1) Yes or 2) No
<bruce_bailey> 1
<Sam> 1
1
<olivia> 1
<Bryan_Trogdon> 1
<loicmn> 1
<FernandaBonnin> 1
MaryJo: references how we did so for Bypass blocks.
BruceB: Defer to when you are done with 428
<Zakim> bruce_bailey, you wanted to discuss input on 397
<maryjom> 3.2.6 Consistent Help — The WCAG2ICT interpretation of this success criterion replaces "sets of Web pages" with "sets of software programs" which are extremely rare - especially for closed functionality software. However, providing consistent access to help is generally considered best practice.
MaryJo: We will work from Google Doc to make adjustments on language. Agree we should add something in
Sam: didn't we remove parsing? Why do we need to address?
<bruce_bailey> w3c/
MaryJo: We had parsing back in to main for 2.0. For 2.2 parsing is removed. For 2.0 and 2.1 it was left in , otherwise we were changing standard in stating it doesn't apply.
<bruce_bailey> 4.1.1 Parsing: does it need to be added in 'problematic for closed'?
MaryJo: For WCAG 2.0 and 2.1 , shares appendix A.
<Chuck> +1!
Sam: If it was removed, is it for record keeping? What is need for this to be back in? Seems to be confusing by adding it back in.
MaryJo: talks to general guidance and reference notes
MaryJo: general guidance was what satisfies AGWG's comments on where to capture it.
Sam: Is his proposal to add it back in to problematic?
<Zakim> bruce_bailey, you wanted to agree present treatment of 4.1.1 is ugly
Sam: Seems to be same thing we are already saying and just adding more content in to say same.
BruceB: I think 2.1 errata and 2.2 are equivalent. 2023 publication uses a lot more words.
MaryJo: We can't definitely say as errata talks to HTML . Mary Jo references Assistive Technologies and parsing examples.
Chuck: Is the ask to add something in WCAG 2.2 specifically? Or to reference what we already have but just in another place in doc?
MaryJo: General guidance is what it is. Problematic for closed doesn't capture parsing at all.
<Chuck> I don't think we should
Original guidance has something in there.
MaryJo: We could point them to notes on general guidance.
<Zakim> bruce_bailey, you wanted to ask why mention 2.1 at all ?
<Sam> +1 to Bruce comment
BruceB: the 2013 wcag2ict will be available, so 2.0 shouldn't be address. For 2.1 and 2.2 , our note would stand. Why do we need to do this with 2024 version of this note?
+1 to Chuck , Sam and Bruce
Chuck: I am not in favor of placing this in problematic sections.
<Sam> can we poll to just keep as is?
<loicmn> +1 not to add anything about 4.1.1 in the "problematic for closed".
<Chuck> +1 leave as is
<Chuck> we already have a decision. need not relitigate
MaryJo: Different jurisdictions are on different versions of WCAG.
MaryJo: AGWG did consult on how this is currently written.
<bruce_bailey> https://
Daniel: Mitch's comment in his own issue mentions he wants to make sur this is just covered.
Daniel: I believe we have confirmed what he raised.
<bruce_bailey> This document, “Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT)” describes how the Web Content Accessibility Guidelines (WCAG) versions 2.0 [WCAG20], 2.1 [WCAG21], and 2.2 [WCAG22] principles, guidelines, and success criteria...
<bruce_bailey> ....can be applied to non-web Information and Communications Technologies (ICT), specifically to non-web documents and software. It provides informative guidance (guidance that is not normative and does not set requirements).
MaryJo: I believe notes suffice.
<Zakim> bruce_bailey, you wanted to ask what AG said ?
BruceB: On AGWG, all I know is what is abstract. I don't think that precludes an approach to 4.1.1
<maryjom> w3c/
MaryJo: references meeting between Wilco and others on guidance originally.
MaryJo: We also reviewed in a Google Doc and made a decision on it too.
Google Doc reference for parsing as listed in MaryJo's comment.
not poll on queue
ugh.
<Zakim> poll, you wanted to move on?
yes please move on poll . go away
<maryjom> POLL: Should we add SC 4.1.1 to SC Problematic for Closed Functionality section? 1) Yes or 2) No
<Sam> 2
2
<Chuck> -infinity
<loicmn> 2
<Bryan_Trogdon> 2
<olivia> 2
<bruce_bailey> 1 , sorry
<ShawnT> 2
<FernandaBonnin> 2
BruceB: I think what is currently in old document is in need of updating.
MaryJo: In new, we don't have anything.
BruceB: It is problematic for closed if you don't ignore it.
MaryJo: Please work on proposal if you'd like and we can bring it back to group.
<bruce_bailey> w3c/
BruceB: I wanted to talk to 397 issue
Issue 397 - Definition of virtual keyboard: Rework the Note for Types of Input
Problem is around readability.
<bruce_bailey> Definition of virtual keyboard: Rework the Note for Types of Input #397
BruceB: Agrees with observation that LOakely says it reads backwards.
<maryjom> Gregg's suggested edits: Some of the many ways to generate keystroke input include speech, eye-gaze, sip-and-puff (and other kinds of switches), sounds, morse code, and, of course, keyboards (small, large, physical, on-screen, floating in the air, etc.)
<bruce_bailey> i proposed something and Gregg proposed something better
Sam: Hesitant to change regarding scoping and virtual keyboards.
… survey is beneficial.
rssagent, make minutes