Meeting minutes
<maryjom> https://
Survey results from q3 onwards
SCs Problematic for Closed: 2.4.4 Link Purpose (In Context)
Proposed content: w3c/
2 said incorporate as is, 1 (Bruce) had concerns over the use of the word "requires"
<bruce_bailey> its not about being incorrect
bruce_bailey: Using requires in 2 ways - 1 about restating/paraphrasing SC, the other is to say what should be done
bruce_bailey: We've had questions from people - read "requires" then assume it is a restatement of the SC
PhilDay: Suggest possible change to language "Assumes the use of ..." instead of "Requires..."
PhilDay: Suggestion - Bruce to look through document, create a single issue to summarise where the language should be changed as above, then we go to the full TF to approve the change to language throughout the document.
<maryjom> https://
https://
bruce_bailey: To look through and create single pull request for clearing up the "requires" language within the SC problematic for closed section.
New introductory section to SC problematic for closed: https://
Edited version of link purpose. New proposal 3 - incorporating changes suggested in survey 2.4.4 Link Purpose (In Context) - Assumes the use of text and context in a programmatically determinable form.
2nd sentence is removed - as it is covered in the intro section
<maryjom> TOPI: SCs Problematic for Closed: 1.4.5 Images of Text
<maryjom> https://
Proposed content: https://
Survey results: 2 said option 10 as is, 1 said option 9 with edits (shown as option 11 in the google doc)
<maryjom> Bruce's alternate proposal from survey: High-quality machine-readable text (and not mere images of text) is needed for assistive technology functionality to provide modification of displayed text (e.g. high contrast, increase of font size)
Option 11: Only state the problem 1.4.5 Images of Text—High-quality machine-readable text (and not mere images of text) is needed for assistive technology functionality to provide modification of displayed text (e.g. high contrast, increase of font size). Not all ICT with closed functionality has the capability to support visual modification of displayed text or images of text, given there is no interoperability with assistive technology an[CUT]
… support.
Or option 12: add last sentence from option 9 to option 11.
Option 12: state problem, then suggest work-around - 1.4.5 Images of Text—High-quality machine-readable text (and not mere images of text) is needed for assistive technology functionality to provide modification of displayed text (e.g. high contrast, increase of font size). ...
… Not all ICT with closed functionality has the capability to support visual modification of displayed text or images of text. Where this is not possible, 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 this success criterion.
maryjom: Don't need the sentence starting "Where this is not possible", which takes it back to options 9 or 11
Agreement is to take options 9 and 11 to full TF
Option 9: Only state the problem 1.4.5 Images of Text—Requires text for high-quality modification of displayed text (e.g. high contrast, increase of font size). Not all ICT with closed functionality has the capability to support visual modification of displayed text or images of text, given there is no interoperability with assistive technology and/or lack of platform support.
Option 11: Only state the problem 1.4.5 Images of Text—High-quality machine-readable text (and not mere images of text) is needed for assistive technology functionality to provide modification of displayed text (e.g. high contrast, increase of font size). Not all ICT with closed functionality has the capability to support visual modification of displayed text or images of text, given there is no interoperability with assistive technology an[CUT]
… support.
SCs Problematic for Closed: 2.1.1 Keyboard
<maryjom> https://
Proposed content: https://
Only change proposed was to deal with the requires language.
Redo survey with options 0 and 5, with the changed language "Requires" changed for "Assumes the use of"
Option 0: Current text in editor’s draft 2.1.1 Keyboard—Assumes operation via a keyboard interface which allows alternative input devices. When a product with closed functionality either does not have a standard keyboard or one cannot be connected, it would need an alternate way to access all functionality that does not require accurate pointing, path-based movements, or specific timings.
Option 5: compromise position Assumes operation via a keyboard interface which also allows for alternative input devices. When a product with closed functionality does not have a standard keyboard or an alternative input device cannot be connected, it may not be possible to satisfy this success criterion. It may be possible to address some user needs (such as offering input methods that support users with low vision, without vision, or limite[CUT]
Option 5: compromise position Assumes operation via a keyboard interface which also allows for alternative input devices. When a product with closed functionality does not have a standard keyboard or an alternative input device cannot be connected, it may not be possible to satisfy this success criterion. ...
… It may be possible to address some user needs (such as offering input methods that support users with low vision, without vision, or limited manual dexterity).
maryjom: Don't think we need any changes to this (apart from Requires language) so will survey the tweaked language
SCs Problematic for Closed: Other SCs that rely on programmatic information
2 responses, both suggested changes
First change was to address "Requires" language, which will already be addressed in Bruce's pull request
Second was a minor editorial to bring consistency between some notes in SC problematic for closed
<maryjom> https://
<maryjom> 1.3.2 Meaningful Sequence — Requires information in a programmatically determinable form. Instead, a closed functionality software equivalent would be to provide a meaningful reading sequence through auditory output or some other non-visual means that helps users correlate the output with the corresponding information displayed on the screen.
<maryjom> 1.3.2 Meaningful Sequence — Requires information in a programmatically determinable form.
Intro section from Success Criteria problematic for closed
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.
https://
[reading through new introductory section in latest editor's draft above]
<bruce_bailey> https://
Survey to be sent out again to get more responses
Now working on open issues / comments
<maryjom> First one: Issue 145 - w3c/
<maryjom> w3c/
Need some generic text to add to the 'sets of' SCs that state that "sets of" may not be applied to non-web documents and software by other regulations.
Discussion starter from Bruce: For example, some local standards such as Section 508 in the US, non-Web documents and non-Web software need not 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
<bruce_bailey> More generally, not all SC will be applicable to all technologies
Not all SCs have been fully adopted in all local regulations and legislation, and may not be applicable to all technologies. For example, some local standards such as Section 508 in the US, non-Web documents and non-Web software need not 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
This to go on the end of Background section.
Not all SCs have been fully adopted in all local regulations and legislation, and may not be applicable to all technologies. WCAG2ICT was also used to determine whether or not to apply certain SCs.
… For example, some local standards such as Section 508 in the US, non-Web documents and non-Web software need not 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
<maryjom> Change to go into: https://
One idea: Local regulations and guidance may not apply this SC, then refer to background section in document
Add this verbiage to those SCs that need it (e.g. sets of) and refer back to the Background paragraph
Work on rest of issues next Thursday
And review Bruce's pull request on changes to "requires" language as well