Meeting minutes
Announcements
<PhilDay> https://
<PhilDay> (For Laura!)
MaryJom: is anyone planning to be at the friday meeting?
<bruce_bailey> +1
Mitchell, Bruce, Laura, yes.
Maryjom: Daniel, please make sure there is an event for Friday sessions.
Download Invite from your W3C account.
Bruce_bailey: is the meeting link the same as this one?
Maryjo: yes.
Maryjom: Talking about the DOJ rule with respect to WCAG2ICT.
Marjoym: We recommend that we do not revamp with that in mind.
Maryjom: It may destabilize the work we have already done. DOJ rule will not be enforced for 2-3 years.
<bruce_bailey> i agree that publishing by June is more important than addressing ADA Title II rule
<PhilDay> I also agree that we should try and publish WCAG2ICT this summer
<Chuck> Laura: I agree but I think that new rule coming out about closed systems. There is additional work we will want to adjust for. Timing doesn't make sense until it is all out.
Maryjom: will they be referencing WCAG in the NPRM for closed systems?
Bruce_bailey: Not if it’s about hardware
<bruce_bailey> USAB does NOT anticipate referencing WCAG with the SSTM rulemaking -- because that rule is about fixed hardware
Maryjom: we may want to provide questions or considerations for policy makers to consider when making statements that include WCAG
<bruce_bailey> WCAG is not applicable to hardware.
Maryjom: That will be worked on outside of the note and we may add an explainer about applying WCAG2ICT.
Maryjom: We can add to that and adjust it as needed vs the note is difficult to adjust quickly.
Mitch11: WCAG2ICT is not just for policy makers.
Mitch11: There are other stakeholders.
Bruce_Bailey: I would suggest we get a resolution in front of AG.
Bruce_Bailey: We (task force) should make a resolution that we will move forward without consideration of DOJ statement.
Bruce_bailey: at this time.
Chuck: We don’t need to take that resolution to AGWG
<PhilDay> Is this the rule that we are all referring to: https://
<bruce_bailey> +1
+1
<maryjom> DRAFT RESOLUTION: Do not make extensive changes to WCAG2ICT Draft due to DoJ's new Rule. This will be handled in other resources outside of the Note.
<bruce_bailey> Yes, that is the URL
+1
<mitch11> +1
<PhilDay> +1
<Bryan_Trogdon> +1
<bruce_bailey> +1
<FernandaBonnin> +1
<Devanshu> +1
PhilDay: Rule referenced above.
<loicmn> +1
RESOLUTION: Do not make extensive changes to WCAG2ICT Draft due to DoJ's new Rule. This will be handled in other resources outside of the Note.
<bruce_bailey> Shortest URL (should you need to type or spell out): https://
<Zakim> PhilDay, you wanted to suggest we include the full URL in the meeting notes for the DOJ final rule
Status of remaining work before next publication
<maryjom> https://
Maryjom: in the US, AT does not Parse but we do not know what happens outside of the US etc.
<PhilDay> Parsing issue: w3c/
This SC addresses parsing.
<PhilDay> Google doc on parsing: w3c/
Maryjom: I have a note that it is rare. Still working on an updated draft.
Maryjom: Wilco and Dan (in the AG working group) do not agree.
<bruce_bailey> Deque WG reps
Bruce_Bailey: both Dan and Wilco have expressed that they have a concern. They won’t likely object but will vote against and will go with the consensus (likely).
Maryjom: will ask for their response to her suggested changes in alignment with their request.
<PhilDay> Google doc on the Parsing draft: w3c/
Dmontalvo: making sure that everyone that needs access to the google doc being referenced, has access to the google doc.
Maryjom: made that change yesterday.
<maryjom> https://
<PhilDay> Issue 4: w3c/
<PhilDay> Discussion on issue 4: https://
Sorry, was kicked out.
Maryjom: Editors meeting next week and will work on notes.
<bruce_bailey> w3c/
Maryjom: Abstract did not change. Task force will review document.
Maryjom: Official Call for Consensus will follow.
<Zakim> bruce_bailey, you wanted to check that we didn't miss anything that needed noteing
Maryjom: editorial issue on use of “requires”
<maryjom> w3c/
Bruce_bailey: to clarify, that is a work item for me?
Maryjom: yes
Maryjom: what is changing because of “requires” and “requiring”.
Bruce_bailey: problem last time is that there were multiple mark down files.
<PhilDay> For general editorial issues: w3c/
Survey results: Issue 145, answers to public comments, and SOTD
<maryjom> https://
Maryjom: First question I have, there were only three respondents. Do people need another week.
<PhilDay> I'm happy to discuss and get them done this week
Chuck: We can discuss on the fly. But I would emphasis that this is not the best operational approach to advancing this work.
<bruce_bailey> +1 to not spending much time today
Chuck: More ideal is more review more participation.
Mitch11: the survey is still open for another week.
Mitch11: makes sense to treat today like a friday working session and take what we have to discuss points.
<PhilDay> Laura_Miller: +1 to mitch11
Maryjom: Start at the top of the survey.
<PhilDay> Google doc : https://
Question 1 - (Part 1 of 3 for Issue 145) Proposed updates to 5 SC that are applied to "sets of documents/software"
<maryjom> https://
<maryjom> Content we were reviewing: https://
<PhilDay> Proposal 3: Chris’ expansion from just “Regulators”
<PhilDay> 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
<PhilDay> note's objectives should 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: Proposal 3 in the survey is what people were leaning toward.
<PhilDay> With Mitch's change: Proposal 3: Chris’ expansion from just “Regulators”
<PhilDay> 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
<PhilDay> note's objectives, should 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.
<Zakim> bruce_bailey, you wanted to affirm headings
loicmn: We shouldn’t use the word “should” there
<PhilDay> Change to remove should: Proposal 3: Chris’ expansion from just “Regulators”
<PhilDay> 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
<PhilDay> note's objectives, have 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.
<PhilDay> Softer version from Phil: Proposal 3: Chris’ expansion from just “Regulators”
<PhilDay> 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
<PhilDay> note's objectives, may wish 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.
"will need to"
<PhilDay> Mitch's language: Proposal 3: Chris’ expansion from just “Regulators”
<PhilDay> 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
<PhilDay> note's objectives, are encouraged 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 for "will need to"
<bruce_bailey> -1 to "encourages"
<PhilDay> Chuck's stronger version: Proposal 3: Chris’ expansion from just “Regulators”
<PhilDay> 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
<PhilDay> 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.
Maryjom: there are so many other issues that are applicable.
<bruce_bailey> +1 that stake holders are better served spending time on other SC
Discussion on editor's notes needed in draft for the public review.
Survey results: Issue 145, answers to public comments, and SOTD
Question 2 - (Part 2 of 3 for Issue 145) Proposals for changes to the Guidance in this Document section
<maryjom> https://
Maryjom: the proposal is to separate one item into two sections, split off the bottom and add a paragraph.
Maryjom: Folks preferred proposals 3 and 4
<PhilDay> Proposal 3: Add new DoJ rule info
<PhilDay> 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.
<PhilDay> 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
<PhilDay> 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.
<PhilDay> 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
<PhilDay> 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.
Maryjom: suggestion is to consider Bruce’s change and if you would like Proposal 3 with the change or if you lean toward proposal 4.
<Zakim> bruce_bailey, you wanted to highlight last survey q
<PhilDay> Bruce change to Proposal 3:
<PhilDay> Proposal 3: Add new DoJ rule info
<PhilDay> 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.
<PhilDay> 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
<PhilDay> 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.
<PhilDay> 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
<PhilDay> document does not specifically say which criteria can or should apply, developers in being responsive to regulation that is not explicit.
Mitch11: what is the motivation/what problem is this solving?
maryjom: there is an open issue.
. (Part 3 of 3 for Issue 145) Proposed changes to the introductory content in the SC Problematic for Closed Functionality section
<maryjom> https://