Meeting minutes
Discussion on SCs that are scoped to markup languages
2 SCs, we are expanding the scope for 1, the other we are keeping to the limited scope of just markup languages
Thoughts for discussion are in the wiki work for today https://
<bruce_bailey> https://
bruce_bailey: Done a 3rd option to look at
maryjom: Status messages - current language expands scope beyond markup language
https://
Above link is from the editor's draft
<maryjom> https://
<maryjom> In [content implemented using markup languages, or that supports status message notifications], status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.
Mitch: if AG approve, then it could be argued it might not be an expansion - it might just be what was originally intended. However, Mary Jo wonders if it was just not fully reviewed
Or do we add note - WCAG only applies it to markup languages, and in the future we suggest it could be broadened in WCAG.
Laura & Bruce - expressed concern that if we go big, it might cause delays at final draft public comments; it also looks like scope creep.
Or, we could put some comments in a wiki - outside the scope of the document, but may be useful for future AGWG updates to WCAG
bruce_bailey: Likes examples in the wiki rather than just in the GitHub issues - which are hard to search.
maryjom: Wiki is also useful to document rationale and decision matrix behind the document
Comments in wiki could be used to feed into WCAG3 or future updates
It's not that we don't think that some of these SCs should be applied more broadly to software that does not use markup languages; instead we are just putting the note in a wiki instead of broadening the scope of the document
<maryjom> Poll: Should we pull back on language in 4.1.3 Status Messages to reign in on scope creep?
<bruce_bailey> +1
+1
<LauraBMiller> +1
<maryjom> +1
<LauraBMiller> Adding that we should capture the detail elsewhere.
mitch11: also a +1 verbally
<mitch11> +1
mitch11: One comment from Gregg that might inform the note. Status messages and others are already covered in other more general SCs.
<bruce_bailey> https://
bruce_bailey: If that is the decision, then my contextualised edit is a good start
Applying SC 4.1.3 Status Messages to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.3 (also provided below) substituting “Where non-web documents or non-web software implement status messages” for “In content implemented”.
[Where non-web documents or non-web software implement status messages] using markup languages, status messages must be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.
NOTE 1: For non-web documents and software where status messages are not implemented using markup languages, there is still a user need to have status messages be programmatically exposed so that they can be presented to the user by assistive technologies without receiving focus. This is typically enabled through the use of accessibility services of the user agent or platform software.
NOTE 2: See also the discussion on Closed Functionality.
Above text is Bruce's proposal from the Google Doc
<maryjom> Normative language for 4.1.3: In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.
NOTE 1 (Phil's version using best practice): For non-web documents and software where status messages are not implemented using markup languages, it is best practice to have status messages be programmatically exposed so that they can be presented to the user by assistive technologies without requiring focus. This is typically enabled through the use of accessibility services of the user agent or platform software.
PhilDay: prefer Bruce's version
<LauraBMiller> Agree.
So we should revert to the previous version
<maryjom> https://
bruce_bailey: the word substitution is more complicated; maybe we should consider removing the word substitution
Both versions will be presented to the TF this week.
<LauraBMiller> Yes
SC problematic for closed for 4.1.3 Status messages
<maryjom> w3c/
<bruce_bailey> https://
<maryjom> Option 1: Original bullet, as-is 4.1.3 Status Messages—requires information in a programmatic determinable form. Additionally, software with closed functionality is not typically implemented using markup languages.
<maryjom> Option 2: With suggested edits 4.1.3 Status Messages—requires information in a programmatic determinable form. Additionally, software with closed functionality is not typically implemented using markup languages. (See Note 1 in Applying SC 4.1.3 Status Messages to Non-web Documents and Software.)
<maryjom> Option 1: Original bullet, as-is 4.1.3 Status Messages—requires information in a programmatic determinable form. Additionally, software with closed functionality is not typically implemented using markup languages.
<maryjom> NOTE 5: Non-web software with closed functionality would need equivalent facilitation to provide access to status messages.
mitch11: Not just closed functionality that does not markup languages. We should just apply this more broadly to closed.
Agreed approach; remove option 2. Edit option 1 to remove additional detail about markup.
<LauraBMiller> +1
Revised language is therefore: 4.1.3 Status Messages—requires information in a programmatic determinable form.
NOTE 5: Non-web software with closed functionality would need equivalent facilitation to provide access to status messages.
(Numbering may need to be reworked)
That brings us to the end of status messages.
That should mean we do not need to change text spacing as it just applied to markup languages
https://
Current language: [For non-web documents or software] content implemented using markup languages [in a way that supports modification of] the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:
Will propose that we remove the substitution to just give: In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:
<bruce_bailey> +1
maryjom: We may need to modify the note to point to content implemented by markup languages that does not expose this for modification
mitch11: Maybe we should poll both versions (with and without word substitution).
<LauraBMiller> Have to jump but have a great weekend (thank you!)
<maryjom> Poll: 1) we need the the existing word substitution in the SC language 2) we should not have any word substitution 3) something else
<bruce_bailey> 2
3
<mitch11> 1, can accept 2
Option 3. Remove 1st word substition, add modification In content implemented using markup languages [in a way that supports modification of] the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:
mitch11: We need to address the modification question - could do it in a note instead
PhilDay: also happy adding modification into a note, and use version with word substitution
<bruce_bailey> +1 for note
May need a new note 3 to cover modification
Mary Jo will create google doc for text spacing and then we can work on the note before the next meeting.