Meeting minutes
Announcements
Pull requests for all that was agreed yesterday - so should be in the document soon
2.1.1 Keyboard - Work on changes due to survey results
<maryjom> https://
Survey showed there was need for some work
Mitch had some edits
<maryjom> In editor's draft: 2.1.1 Keyboard—Requires 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.
Google doc being created for SC problematic for closed: 2.1.1 Keyboard
<maryjom> https://
Option 2: Mitchell’s editorial Requires operation via a keyboard interface which allows alternative input devices. When a product with closed functionality does not have a standard keyboard and 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.
(Above are both in the SC problematic for closed section, not the main SC for 2.1.1 Keyboard)
Option 3: closed cannot conform to 2.1.1 Requires operation via a keyboard interface which allows alternative input devices. When non-web software is closed to keyboards, it cannot conform to this criterion.
Option 3: closed cannot conform to 2.1.1 Requires operation via a keyboard interface which allows alternative input devices. When non-web software is closed to keyboards, it cannot satisfy this criterion.
mitch11: Option 2 is one extreme, option 3 is the other extreme
mitch11: The point of keyboard interfaces is to allow users to attach input interfaces that work for them. Closed systems cannot achieve this intent.
mitch11: Or at least we should point out that it is problematic. We should not say you meet criterion if you cannot do this
<maryjom> Intent for 2.1.1: https://
Chuck: Was looking if we ever say SC cannot be satisfied elsewhere. Cannot see where we have done it before, but have used softer language such as 3.1.1. "May not be able to meet this SC".
Option 3 now edited: Option 3: closed cannot conform to 2.1.1 - Mitchell Requires operation via a keyboard interface which also allows alternative input devices. When non-web software is closed to keyboards it may not be able to meet this success criterion.
Option 4: no bright line - Mitchell Requires operation via a keyboard interface which allows alternative input devices.
Option 5: compromise position - Phil Requires operation via a keyboard interface which also allows for alternative input devices. When a product with closed functionality does not have a standard keyboard and an alternative input device cannot be connected, ...
… it may be difficult to satisfy this success criterion although 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).
Further edit of option 5:
Option 5: compromise position - Phil Requires operation via a keyboard interface which also allows for alternative input devices. When a product with closed functionality does not have a standard keyboard and 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).
Further edit: Requires 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).
Option 5 to take to full TF for review
SC problematic for closed: 1.4.10 Reflow
<maryjom> https://
Results: 1 for option 0, 2 for option 4 as is, 2 for option 4 with changes, 3 for option 3A
Google doc for discussion: https://
Option 0: What is in the document now If the content technology and platform software do not support reflow, it may not be possible for non-web software to meet this success criterion, meaning the software application would then fail this success criterion.
Option 4: Change to option 3 to better cover large screen without scrolling NOTE: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width of 320 CSS pixels (or 1280 CSS pixels wide at 400% zoom) for vertical scrolling and a height of 240 CSS pixels (or 1024 CSS pixels at 400% zoom) for horizontal scrolling. ...
When the non-web document or software does not support these dimensions for scrolling, reflow is highly encouraged as this capability is essential to persons with low vision. As a reasonable benchmark, implement and evaluate at the nearest possible equivalent size to what the Reflow success criterion specifies. For systems that do not support zoom, scrolling, and reflow, the user need is often addressed by other means (including but not limi[CUT]
… sufficiently large text and single screen designs).
Option 3A: Mitchell’s edits to Option 3 NOTE: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width of 320 CSS pixels for vertical scrolling content and a height of 240 CSS pixels for horizontal scrolling content. ...
… When the underlying user agent or platform does not support these dimensions for scrolling, reflow is highly encouraged as this capability is essential to persons with low vision. As a reasonable benchmark, implement and evaluate at the nearest possible equivalent size to what the Reflow success criterion specifies.
Option 3A & 4 are similar for first paragraph - option 3A is simplified and looks like a good improvement
Modified 3A to include elements of option 4 NOTE: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width of 320 CSS pixels for vertical scrolling content and a height of 240 CSS pixels for horizontal scrolling content. ...
… When the underlying user agent or platform does not support these dimensions for scrolling, reflow is highly encouraged as this capability is essential to persons with low vision. As a reasonable benchmark, implement and evaluate at the nearest possible equivalent size to what the Reflow success criterion specifies. For systems that do not support zoom, scrolling, and reflow, user needs such as low vision are often addressed by other mean[CUT]
… limited to using sufficiently large text and single screen designs).
Above would replace notes 6 & 7
Existing notes 6 & 7
NOTE 6: If the content technology and platform software do not support reflow, it may not be possible for non-web software to meet this success criterion, meaning the software application would then fail this success criterion.
NOTE 7: Certain platforms do not support adjusting viewports to an equivalent of 320 CSS pixels wide or 256 CSS pixels high. Likewise, some platforms have limitations on zooming as high as 400% for the larger measurements of 1280 CSS pixels wide or 1024 CSS pixels high. In such cases, implement and evaluate at the nearest possible equivalent size to what the Reflow success criterion specifies.
Working group thinks that 6 & 7 can be replaced by new note 3A above, Mary Jo to check with Sam for his input prior to running by TF
<maryjom> https://
Further refinement to option 3A
Option 3A: Mitchell’s edits to Option 3 NOTE: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 240 CSS pixels for horizontal scrolling content. ...
… When the underlying user agent or platform does not support these dimensions for scrolling, reflow is highly encouraged as this capability is essential to persons with low vision. As a reasonable benchmark, implement and evaluate at the nearest possible equivalent size to what the Reflow success criterion specifies. ...
For systems that do not support zoom, scrolling, and reflow, user needs such as low vision are often addressed by other means (including but not limited to using sufficiently large text and single screen designs).
Latest refinement of Option 3A above to be put in survey to full TF (after getting Sam's input)
SC Problematic for Closed Functionality - SCs that require programmatic information (4.1.2)
<maryjom> https://
4.1.2 Name, Role, Value. If we get something for this, may also use it for 1.3.2 Meaningful sequence and others
Option 5 - Mitchell’s proposal, “help meet the intent”
4.1.2 Name, Role, Value—Requires information in a programmatically determinable form. 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.
alternative wording for option 5: ... would help meet some user needs
Consensus: use option 5 for Name role value.
Mary Jo to use this in drafting content for info & relationship
Are there any other SCs problematic that have to do with programmatic information? Current list: (1.1.1 Non-text Content, 1.3.2 Meaningful Sequence, 3.1.1 Language of page, 3.1.2 Language of parts)
Which criteria should be listed?
There will be 1 survey question for these all together.
Any additional SCs to be listed - send email to Mary Jo