Meeting minutes
Announcements
<PhilDay> Reminder – there will be no meeting next week (9th April) but we will be meeting on the 16th April 2026.
<PhilDay> Survey: information in-line or links out to separate content?
<PhilDay> https://
<PhilDay> Survey link: https://
GreggVan: I prefer both the information in-line and links out.
2.1.3 Keyboard (No Exception)
<PhilDay> Link to issue: w3c/
<PhilDay> Applying SC 2.1.3 Keyboard (No Exception) to non-web documents and non-web software
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.3.
<PhilDay> NOTE
<PhilDay> Keyboard interface does not refer to a physical device but to the service of platform software (e.g. operating system, browser, etc.) that provides the software with keystrokes from any keyboard or keyboard substitute. When the non-web software supports such a device-independent service of the platform software, and the non-web software
<PhilDay> functionality is made fully operable through the service, then this success criterion would be satisfied.
<PhilDay> NOTE
<PhilDay> A "device-independent keyboard interface service" refers to the platform service that provides keystrokes to any software running on the platform.
<PhilDay> NOTE
<PhilDay> Inclusion of an on-screen keyboard can be done as well but does not satisfy this requirement since it does not allow for the use of keyboard alternatives whereas support of input from the device-independent keyboard interface service does.
<PhilDay> NOTE
<PhilDay> This success criterion does not imply that non-web software always needs to directly support a keyboard or “keyboard interface” if one is not provided by the platform software. But if one is provided, the software needs to make all functionality available through it - unless the exception applies.
<PhilDay> NOTE
<PhilDay> This success criterion also does not imply that non-web software always needs to provide its own virtual keyboard. But if it does, then the non-web software still needs to support keyboard input from any keyboard interface provided by the platform software.
<PhilDay> NOTE
<PhilDay> See also the Comments on Closed Functionality.
<PhilDay> And proposed content for SC problematic for closed functionality (again, derived from 2.1.1):
<PhilDay> Assumes operation via a keyboard interface which also allows for alternative input devices. It may not be possible to satisfy this success criterion when the ICT does not have a built-in keyboard, and it also does not support an alternative input method (hardware or software) that provides keyboard-like access to all functionality.
<PhilDay> NOTE
<PhilDay> A keypad that provides full access to functionality might be considered a keyboard.
<PhilDay> Link to results for this question: https://
<PhilDay> Loic's comment from survey: I suggest that we use the already existing approach for 2.1.1 Keyboard (https://
<PhilDay> that can be run on a software platform that provides a device-independent keyboard interface service". Then we have specific notes for non-web software, providing detailed information.
<PhilDay> I don't see any reason why not to apply the same thinking to 2.1.3.
PhilDay: Do we agree with Loic, keep it as is, or suggest something else.
<bbailey> +1 to Loic proposal
<PhilDay> Gregg: +1 to Loic
<PhilDay> Sam: +1 to Loic
Sam present+
Sam: present+
Gregg: Should have a note that if there is active scripting in the document, it should be software
bbailey: If we are making changes to this, we probably need to also change the note.
<bbailey> https://
PhilDay: Next are the comments on Closed Functionality
<PhilDay> SC problematic: Assumes operation via a keyboard interface which also allows for alternative input devices. It may not be possible to satisfy this success criterion when the ICT does not have a built-in keyboard, and it also does not support an alternative input method (hardware or software) that provides keyboard-like access to all functionality.
<PhilDay> NOTE
<PhilDay> A keypad that provides full access to functionality might be considered a keyboard.
<PhilDay> DRAFT RESOLUTION: For 2.1.3 Keyboard (No Exception), incorporate proposal into the editor’s draft, with edits shown in the meeting minutes (split up documents and software) above
<Daniel> +1
<Laura> +1
<PhilDay> +1
<bbailey> +1
<PhilDay> Sam: +1
<GreggVan> +1
RESOLUTION: For 2.1.3 Keyboard (No Exception), incorporate proposal into the editor’s draft, with edits shown in the meeting minutes (split up documents and software) above
2.2.3 No Timing
<PhilDay> Link to issue: w3c/
<PhilDay> Applying SC 2.2.3 No Timing to non-web documents and non-web software
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.3.
<PhilDay> Link to results for this question: https://
<PhilDay> DRAFT RESOLUTION: For 2.2.3 No Timing, incorporate proposal into the editor’s draft, as-is
<Laura> +1
<PhilDay> +1
<GreggVan> +1
<bbailey> +1
<Daniel> +1
<PhilDay> Sam +1
<GreggVan> SAM +1
RESOLUTION: For 2.2.3 No Timing, incorporate proposal into the editor’s draft, as-is
2.2.4 Interruptions
<PhilDay> Link to issue: w3c/
<PhilDay> Applying SC 2.2.4 Interruptions to non-web documents and non-web software
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.4.
<PhilDay> Link to results for this question: https://
<GreggVan> +1
<bbailey> Glad to see some SC where we dodn't need to split into non-web documents and non-web software!
<PhilDay> DRAFT RESOLUTION: For 2.2.4 Interruptions, incorporate proposal into the editor’s draft, as-is
<PhilDay> +1
<Laura> +1
<Daniel> +1
<GreggVan> SAM +1
<GreggVan> +1
<bbailey> +1
RESOLUTION: For 2.2.4 Interruptions, incorporate proposal into the editor’s draft, as-is
2.2.5 Re-authenticating
<PhilDay> Link to issue: w3c/
<PhilDay> Applying SC 2.2.5 Re-authenticating to non-web documents and non-web software
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.5.
<PhilDay> NOTE
<PhilDay> See also the Comments on Closed Functionality.
<PhilDay> And the proposed content for SC problematic for closed:
<PhilDay> 2.2.5 Re-authenticating (Level AAA) — ICT with closed functionality may offer more limitations on how much data can be kept between sessions. This is particularly true of systems that are designed to be used in public environments.
<PhilDay> Link to results for this question: https://
<PhilDay> DRAFT RESOLUTION: For 2.2.5 Re-authenticating, incorporate proposal into the editor’s draft, as-is
<GreggVan> +1
<PhilDay> +1
<Laura> +1
<bbailey> +1
<GreggVan> SAM +1
<Daniel> +1 counting Phil's addition
RESOLUTION: For 2.2.5 Re-authenticating, incorporate proposal into the editor’s draft, as-is
1.2.6 Sign Language (Prerecorded) (Level AAA)
<PhilDay> w3c/
<PhilDay> Latest proposal
<PhilDay> Applying SC 1.2.6 Sign Language (Prerecorded) to non-web documents and non-web software
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.6.
<PhilDay> NOTE
<PhilDay> To date, meeting this success criteria has proven to be challenging, as it is logistically impossible for all existing sign language interpreters to handle all content. Emerging technologies may, in the future, allow translation from text or speech to sign language directly. At that time, those who need sign language could use such an automated
<PhilDay> translation tool in the same way people who are blind use a screen reader. This would give people who need to have audio content presented in sign language the same ability to access to this content that people who are blind have access to by using their screen readers.
<PhilDay> As always, authors should not rely on such solutions until they are commonly available at a quality accepted by the signing community. In the meantime, providing sign language interpretation continues to be a need for native sign language users, especially in the context of any public service content.
<PhilDay> Direct link: w3c/
GreggVan: to say that it's impossible for sign language to handle the content is really that they couldn't handle the volume so should say that.
<PhilDay> bbailey: not clear that we are talking about human sign language interpreters
bbailey: I don't think it's clear that we are talking about human intepretters.
GreggVan: Should we add the word human? I've added the word "human"
<bbailey> seems a little hyperbolic
GreggVan: The volume of content generated is enormous.
bbailey: I'm uncomfortable with where this is going because it says that it will slow down the production cycle.
<PhilDay> Alternative proposal: To date, meeting this success criteria has proven to be challenging, as it is logistically impossible for all existing human sign language interpreters to handle the volume of content that could be generated.
Sam: I agree with the sentiment, but not sure if we can avoid the day/year reference as it is at the moment or on demand.
GreggVan: it's out of scale. It's not that it is just going too fast. Not just anyone can do sign language.
<bbailey> Proposed: To date, meeting this success criteria has proven to be challenging, as there are not enough human sign language interpreters available to handle the volume of video content.
Daniel: This phrase is saying what we are saying.
<PhilDay> Gregg edit: To date, meeting this success criteria has proven to be challenging, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content.
<bbailey> Proposed: To date, meeting this success criteria has proven to be challenging, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content.
<PhilDay> Latest proposed text with Bruce & Gregg's suggestions:
<PhilDay> Applying SC 1.2.6 Sign Language (Prerecorded) to non-web documents and non-web software
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.6.
<PhilDay> NOTE
<PhilDay> To date, meeting this success criteria has proven to be challenging, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content. Emerging technologies may, in the future, allow translation from text or speech to sign language directly. At that time, those who need sign language could use
<PhilDay> such an automated translation tool in the same way people who are blind use a screen reader. This would give people who need to have audio content presented in sign language the same ability to access this content that people who are blind have access to by using their screen readers.
<PhilDay> As always, authors should not rely on such solutions until they are commonly available at a quality accepted by the signing community. In the meantime, providing sign language interpretation continues to be a need for native sign language users, especially in the context of any public service content.
<bbailey> Proposed: As compared to captioning and audio description, sign language interpretation is a very specialized skill.
PhilDay: we are just talking about the first sentence of the note.
GreggVan: "volume being generated"? Otherwise it sounds like "all of history"
<bbailey> Proposed: To date, meeting this success criteria has proven to be infeasible, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content being produced. As compared to captioning and audio description, sign language interpretation is a very specialized skill.
<PhilDay> To date, meeting this success criteria has proven to be logistically impossible, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content being generated.
<PhilDay> Full text: Applying SC 1.2.6 Sign Language (Prerecorded) to non-web documents and non-web software
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.6.
<PhilDay> NOTE
<PhilDay> To date, meeting this success criteria has proven to be infeasible, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content being produced. As compared to captioning and audio description, sign language interpretation is a very specialized skill. Emerging technologies may, in the
<PhilDay> future, allow translation from text or speech to sign language directly. At that time, those who need sign language could use such an automated translation tool in the same way people who are blind use a screen reader. This would give people who need to have audio content presented in sign language the same ability to access this content that
<PhilDay> people who are blind have access to by using their screen readers.
<PhilDay> As always, authors should not rely on such solutions until they are commonly available at a quality accepted by the signing community. In the meantime, providing sign language interpretation continues to be a need for native sign language users, especially in the context of any public service content.
GreggVan: Could say "specialized skills for another language". People don't realize that signing is another language.
<PhilDay> DRAFT RESOLUTION: For 1.2.6 Sign Language (Prerecorded), incorporate proposal into the editor's draft, with edits shown in the meeting minutes above
<bbailey> +1
<Daniel> +1
<GreggVan> +1
<Laura> +1
<PhilDay> +1
<GreggVan> SAM +1
RESOLUTION: For 1.2.6 Sign Language (Prerecorded), incorporate proposal into the editor's draft, with edits shown in the meeting minutes above
PhilDay: we can work on the introduction now.
introductory text for AAA
<PhilDay> Editor's draft: https://
bbailey: at the end of the last call I made work for Daniel.
Daniel: IDs for closed functionality?
bbailey: Yes
<PhilDay> Section that may need some work to introduce level AAA: https://
bbailey: my recollection, we went to more simple phrasing. We merged it? Introduction for AAA.
PhilDay: Issue 811. Yes, we have done this and merged it into the draft.
PhilDay: Guidance for Level AAA, we list SCs in Editors note.
<PhilDay> EDITOR'S NOTE
<PhilDay> This is where we could add a note with the overarching caveats regarding Level AAA criteria and the application of these SC to non-web documents and non-web software. Here is the info in WCAG 2.2 regarding Level AAA conformance. We will need to have some proposals for what content would actually be included in here.
<PhilDay> From the WCAG 2 Layers of Guidance section of WCAG 2.2:
<PhilDay> Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive, language, and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, Making Content Usable for
<PhilDay> People with Cognitive and Learning Disabilities, as well as to seek relevant advice about current best practice to ensure that web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs.
<PhilDay> From the Conformance level section of WCAG 2.2:
<PhilDay> NOTE 1
<PhilDay> It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.
<PhilDay> Proposal for editor's note
GreggVan: It should say "these apply as written".
<PhilDay> Replace "This is where we could add a note..."
<PhilDay> "These 2 following quotes apply as written to non-web documents and non-web software." then the 2 notes (from guidance and conformance).
<GreggVan> Draft resolution: Replace the folowing placeholder text "This is where we could add a note with the overarching caveats regarding Level AAA criteria and the application of these SC to non-web documents and non-web software. Here is the info in WCAG 2.2 regarding Level AAA conformance. We will need to have some proposals for what content would actually be included in here.
<PhilDay> DRAFT RESOLUTION: Replace placeholder text in editor's note with edits as above
<GreggVan> with 'These two notes apply as written to non-web software and non-web documents
ACTION: PhilDay to create draft PR, then add all meeting attendees as reviewers for the draft PR
<PhilDay> Daniel: Suggests tweaking the wording so we use something other than "apply as written" as this is used for SCs
<Zakim> bbailey, you wanted to discuss minor quibble
bbailey: I'd like to see what the PR looks like. We may not need the editors note, and may just need the paragraph above and the excerpts.
<PhilDay> bbailey: want to see the PR - we may not need the editor's note - just have an introductory sentence
<PhilDay> ... Also from note 1 of the conformance level of WCAG 2.2 (then lose the nested NOTE 1)
<PhilDay> PhilDay to discuss with AG WG chairs the approach for reviewing the first few level AAA SCs