WCAG2ICT Task Force Teleconference

Meeting minutes

Announcements

Extra Friday meeting happening tomorrow. Will pickup any tweaks from today

Will also be working on input from Dan on 4.1.1.

News item: IBM have introduced a co-location mandate, so Mary Jo is impacted. 30 days to make a decision. So likely leaving by end of July at latest.
… This means that we need to focus to get WCAG2ICT note published before Mary Jo leaves.

Status of remaining work before next publication

<maryjom> https://github.com/w3c/wcag2ict/wiki/Work-left-for-second-public-draft

All but parsing & editor's notes is in survey or complete. Editors are working on notes, and hope to have these surveyed next week

Aim is to get all content complete by May 10th.

That gives the TF a week to review the whole document.

Last few public comments are being surveyed. Issue 4 - need to see what the results of the survey are

mitch11: Needs to drop in 30 mins

Survey results: Issue 145, answers to public comments, and SOTD

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-miscellaneous2/

Question 1: Proposed updates to 5 SC that are applied to "sets of documents/software"

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-miscellaneous2/results#xq1

Google doc with proposals: https://docs.google.com/document/d/1XBgjeXvjB72p3OQogJtDUuWpzZcW-OWqxCixz3-jWz4/edit#heading=h.jte1knel6ihr

<bruce_bailey> My editorial pass (on replacing "requir* where possible) is:

<bruce_bailey> https://github.com/w3c/wcag2ict/pull/348/files?diff=split&w=1

6/7 preferred proposal 3, 1 preferred proposal 2.

Minor editorial to proposal 3

<maryjom> https://docs.google.com/document/d/1XBgjeXvjB72p3OQogJtDUuWpzZcW-OWqxCixz3-jWz4/edit#heading=h.79s2obg4dqw6

Above link is direct link to proposal 3

ChrisLoiselle: Stakeholders - was meant to be broader than just regulators

ChrisLoiselle: could be implementers instead of stakeholders

<bruce_bailey> +1 to use implementors

Sam: Stakeholders seemed extra - better to just have regulators and implementers

Sam: Fine with 3, but good to simplify if possible

<Zakim> mitch, you wanted to suggest "Regulators or other implementors"

+1 to mitch11's suggestion

mitch11: Suggested "Regulators or other implentors"

bruce_bailey: Just say implementers

ChrisLoiselle: Fine with that suggestion

Modified version of proposal 3: Proposal 3: Chris’ expansion from just “Regulators”

NOTE 1: See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or pieces of software is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.) Implementers of this note's objectives will need to consider if

this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context.

mitch11: Surprised that we dropped regulators - thought that was the main point of this. Implementers is a bit more vague. Implementers such as regulators may be better

<Sam> +1 to what Mitch said. I first thought that implementors means developers

<shadi> +1 to Mitch's suggestion

Proposal 3: Mitch: implementers such as regulators

need to consider if this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context.

<ChrisLoiselle> https://www.britannica.com/dictionary/regulator

<bruce_bailey> I have come full circle on this.

bruce_bailey: 2013 version did not mention regulators, only mentioned regulation a couple of times. So now think we do not need to address regulators directly

mitch11: If we don't need to address regulators, just don't add the sentence?

<bruce_bailey> I liked having something for stakeholders.

<bruce_bailey> Please remind us what "as-is" is before poll.

Proposal 0: Current relevant text in editor’s draft (unchanged)

(for non-web documents)

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple [non-web documents in a set of non-web documents].

(for software programs)

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple [software programs in a set of software programs].

NOTE 2: Individual documents or software programs (not in a set) would automatically meet this success criterion because this success criterion applies only to things that appear in a set.

NOTE 3: Although not required by the success criterion, being able to bypass blocks of content that are repeated within non-web documents or software directly addresses user needs identified in the Intent section for this Success Criterion, and is generally considered best practice.

NOTE 4: Many software user interface components have built-in mechanisms to navigate directly to / among them, which also have the effect of skipping over or bypassing blocks of content.

Above text is labelled as Proposal 0 in the google doc

<maryjom> POLL: Which proposal do you prefer? 0) Leave as-is without addressing regulators 2) Proposal 2 or 3) Proposal 3?

<Sam> 0

Proposal 2: Bruce’s suggested edit

NOTE 1: See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or pieces of software is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.) Regulators need to consider if this success criterion is

appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context.

Proposal 3: Chris’ expansion from just “Regulators”

NOTE 1: See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or pieces of software is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.) Stakeholders, such as regulators or other implementers of this

note's objectives, will need to consider if this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context.

3, with simplification to state: "implementers"

Mike_Pluke: could put in 3rd person: "Those who are implementing this note"

<Chuck> Regulators or other implementers of this note's objectives will need to consider if this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context.

<Chuck> Implementers of this note's objectives will need to consider if this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context.

Mike_Pluke: Also somewhat ambiguous - could refer directly to WCAG2ICT rather than NOTE1

<shadi> "document" instead of "note"?

Proposal 3A: simplifed: just implementers

this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context.

Proposal 3B: Mitch: implementers such as regulators

need to consider if this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context.

Proposal 3C: Mike: simplify & 3rd person

Proposal 3B: Mitch: implementers such as regulators

NOTE 1: See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or pieces of software is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.) Those implementing this document (WCAG2ICT) will need to

consider if this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context.

<bruce_bailey> +1 that "note" is ambiguous in context.

Proposal 3C: Mike: simplify & 3rd person

NOTE 1: See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or pieces of software is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.) Those implementing this document (WCAG2ICT) will need to

consider if this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context.

<maryjom> POLL: Which do you prefer? 1) Option 0, 2) Option 3A, 3) Option 3B, 4) Option 3C or 5) something else

<shadi> 4

<Mike_Pluke> 4

<Sam> 1 ok with 4

<ChrisLoiselle> 4

<Bryan_Trogdon> 4

<Devanshu> 4

<FernandaBonnin> 4

<bruce_bailey> 4

RESOLUTION: Incorporate proposal 3C in IRC above into the general guidance for the 5 SC that pertain to “sets of documents/software programs” with the editorial change.

Question 2: Proposals for changes to the Guidance in this Document section

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-miscellaneous2/results#xq2

Original text: https://w3c.github.io/wcag2ict/#guidance-in-this-document

Proposal 3: Add new DoJ rule info

Reasoning given in survey: This section can and should be updated to be responsive to the new rule under ADA Title II for website and mobile app accessibility -- which references WCAG2ICT as the authoritative source for addressing application of WCAG to non-web documents and software.

Not all success criteria have been fully adopted in all local regulations and legislation, and may not be applicable to all technologies. WCAG2ICT has been used in some regulations to determine whether or not to apply certain success criteria. For example, some local standards such as Section 508 in the US, and EN 301 549 in Europe, state that

non-Web documents and non-Web software do not need to comply with WCAG 2.0 Success Criteria 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification. In addition, EN 301 549 also states that non-Web software does not need to comply with 2.4.2 Page titled and 3.1.2 Language of parts.

In contrast, the U.S. Department of Justice regulation Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities expects implementers to utilize the guidance in this document to determine the applicability and how to apply the requirements to mobile applications. Since this

document does not specifically say which criteria can or should apply, regulators should consider the applicability of individual success criteria to non-web documents and software.

Proposal 4: Do not include the new paragraph(s)

Reasoning given in survey: I think that all the info about what other standards have done in the past is more than we should include. They may change their mind in the future. We should leave their judgements to them and not freeze them by documenting them here. A simple comment should suffice.

3 preferred proposal 4, others preferred proposal 3

<bruce_bailey> Now that we have "implementors" my comment in survey is OBE.

<Zakim> mitch, you wanted to say I can accept either. Dropping, thanks!

PhilDay: Thinks it is useful to refer to other sources like EN 301 549, Section 508, and DOJ

We do have it in background

<ChrisLoiselle> comments-on-conformance.md and introduction.md mention the word regulations

<bruce_bailey> Mention of past regulation is in Background section.

https://w3c.github.io/wcag2ict/#background

New note would be added to end of Guidance section

https://w3c.github.io/wcag2ict/#guidance-in-this-document

<ChrisLoiselle> https://github.com/search?q=repo%3Aw3c%2Fwcag2ict+regulations&type=code if that helps for searching for the word regulations

Proposal 3: edited

document does not specifically say which criteria can or should apply. Those implementing this document (WCAG2ICT) should consider the applicability of individual success criteria to non-web documents and software.

<maryjom> POLL: Should we include the proposed text (above) into WCAG2ICT document? 1) Yes or 2) No

1, but would accept 2

<bruce_bailey> 1

<ChrisLoiselle> 1

<Sam> 1

<shadi> 1

<Bryan_Trogdon> 1

<Devanshu> 1

<LauraMiller> 1

bruce_bailey: Make title a hyperlink. Will add comment in google doc

Shadi: EN 301 549 does not need to comply. Could rephrase to say "does not apply" instead of using the contentious term "comply"

Shadi: swap sentence- SC .... do not apply to non web

<LauraMiller> lower case "those"

Snippet to include Shadi's latest edit: For example, some local standards such as Section 508 in the US, and EN 301 549 in Europe, state that WCAG 2.0 Success Criteria 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification do not apply to

non-Web documents and non-Web software. In addition, EN 301 549 also states that non-Web software does not need to comply with 2.4.2 Page titled and 3.1.2 Language of parts.

<shadi> For example, some local standards such as Section 508 in the US, and EN 301 549 in Europe, state that WCAG 2.0 Success Criteria 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification do not apply to non-Web documents and non-Web software. In addition, EN 301 549 also states that 2.4.2 Page titled

<shadi> and 3.1.2 Language of parts does not apply to non-Web software.

<maryjom> DRAFT RESOLUTION: Incorporate the Proposal 3, with edits from proposed by Shadi (above in IRC), into the Guidance in this Document section.

<bruce_bailey> +1

<shadi> +1

<Mike_Pluke> +1

Proposal 3: with Shadi’s edit

2.0 Success Criteria 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification do not apply to non-Web documents and non-Web software. In addition, EN 301 549 also states that 2.4.2 Page titled> and 3.1.2 Language of parts does not apply to non-Web software.

In contrast, the U.S. Department of Justice regulation Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities (89 FR 31320, 24 April 2024) directs implementers to utilize the guidance in this document to determine the applicability and how to apply the requirements to

mobile applications. Since this document does not specifically say which criteria can or should apply, those implementing this document (WCAG2ICT) should consider the applicability of individual success criteria to non-web documents and software.

<maryjom> DRAFT RESOLUTION: Incorporate the updated Proposal 3 (above in IRC), into the Guidance in this Document section.

<shadi> +1 (without > chevron)

<Devanshu> +1

Proposal 3: with Shadi’s edit

2.0 Success Criteria 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification do not apply to non-Web documents and non-Web software. In addition, EN 301 549 also states that 2.4.2 Page titled and 3.1.2 Language of parts does not apply to non-Web software.

In contrast, the U.S. Department of Justice regulation Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities (89 FR 31320, 24 April 2024) directs implementers to utilize the guidance in this document to determine the applicability and how to apply the requirements to

<bruce_bailey> +1

<Mike_Pluke> +1

<ChrisLoiselle> +1

<Bryan_Trogdon> +1

RESOLUTION: Incorporate the updated Proposal 3 (above in IRC), into the Guidance in this Document section.

Question 3: Proposed changes to the introductory content in the SC Problematic for Closed Functionality section

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-miscellaneous2/results#xq3

Proposal 0: Current editor’s draft unchanged

For context, the following is the current introductory text for Appendix A. Success Criteria Problematic for Closed Functionality:

There are Success Criteria that can be problematic for developers of ICT with closed functionality. Some criteria discuss making information available in text (which can be read by assistive technologies), making it “programmatically determinable” (rendered by a user agent and readable by assistive technologies), or doing something else to make

content compatible with assistive technologies. Where ICT with closed functionality doesn't support use of assistive technology or the platform is not sophisticated enough to have an accessibility API, providing equivalent information and operation through another mechanism, such as functions built into the software that behave like assistive

technology, would help meet the intent of these success criteria.

Other Success Criteria would apply to systems with closed functionality either if they are partially closed or if they allow for the connection of some types of devices. As an example, Success Criterion 2.1.1 Keyboard would apply to systems which are closed to screen readers, but have a physical keyboard or a connector for standard keyboards. While

these criteria, as written, are not always applicable to closed functionality, most of them can inform and aid development of built-in features needed to make closed functionality products accessible.

For non-web software on closed functionality products, alternate accessibility provisions might be needed to cover the user needs addressed by the following Success Criteria:

<Sam> +1

Proposal 1: From PR 330

Modifies the last paragraph of the above content to read:

For non-web software on closed functionality products, regulators should consider the applicability of individual WCAG 2 success criteria. Alternate or additional accessibility provisions might be needed to cover the user needs addressed by the following:

<maryjom> rssagent, make minutes

Proposal 3: Avoid using “Regulators” alone + Gregg’s edit

From Chris’ comment that it isn’t just regulators using the guidance - broaden who is using this guidance.

For non-web software on closed functionality products, stakeholders or implementors of this note's objectives should consider the applicability of individual WCAG 2 success criteria. Alternate or additional accessibility provisions might be needed to cover the user needs addressed by the following:

Proposal 4: Make the text stronger + Gregg’s edit

For non-web software on closed functionality products, regulators should consider the applicability of individual WCAG 2 success criteria on a criterion-by-criterion basis. Alternate or additional accessibility provisions might be needed to cover the user needs addressed by the following:

<Sam> option 4 is good with me now

<Zakim> LauraMiller, you wanted to say editorial typo in next paragraph, should be lower case "those"

<Zakim> PhilDay, you wanted to suggest we change to "Those who implement this document (WCAG2ICT)

Sam: happy with 4 as well

Previously, we had a split in results between 0, 3, and 4

<maryjom> Poll: Which do you prefer? 1) Proposal 0, 1) Proposal 3 or 2) Proposal 4 with proposals edited for consistency with what we have previously agreed.

Poll assumes we would make the edits to consistent language: "Those who implement this document (WCAG2ICT)”

<bruce_bailey> 4 (i think)

<ChrisLoiselle> 4

<maryjom> Poll: Which do you prefer? 1) Proposal 0, 2) Proposal 3 or 3) Proposal 4 with proposals edited for consistency with what we have previously agreed.

<bruce_bailey> (3)

<ChrisLoiselle> 3, which is proposal 4 :)

<shadi> option 3 (proposal 4)

<Mike_Pluke> 3

<Sam> 3

<Bryan_Trogdon> 3

<FernandaBonnin> 3

<Devanshu> 3

Revised version of text included for ref

Proposal 4: Make the text stronger + Gregg’s edit

For non-web software on closed functionality products, those who implement this document (WCAG2ICT) should consider the applicability of individual WCAG 2 success criteria on a criterion-by-criterion basis. Alternate or additional accessibility provisions might be needed to cover the user needs addressed by the following:

RESOLUTION: Update the SC Problematic for closed functionality section using Proposal 4 with edits noted for consistency.

+1 to longer meeting if needed

– DRAFT –
WCAG2ICT Task Force Teleconference

02 May 2024

Attendees