Meeting minutes
<PhilDay> Starting with reflow
1.4.10 Reflow
<maryjom> https://
<PhilDay> This started from a public comment, on where tech does not support an SC, but biggest example is Reflow
<bruce_bailey> https://
<PhilDay> 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.
<PhilDay> Option 1: Sam - Revert to former language NOTE: 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.
<bruce_bailey> https://
<PhilDay> Option 2: Phil’s 2024-02-2 from working session (formerly Option 7 as discussed on 2 Feb.) NOTE: This success criterion canis only able to be applied to non-web documents or software where the underlying platform permits a viewport size of 320 by 240 px or equivalent. WhenIf the non-web document or software does not support a viewport of this size, reflow is highly encouraged, but this SC cannot be applied, as written.
<PhilDay> Option 3: Mary Jo a variation of Phil’s 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. ...
<PhilDay> ... 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.
<PhilDay> Edited version of option 2 as cut & paste failed.
<PhilDay> Option 2: Phil’s 2024-02-2 from working session (formerly Option 7 as discussed on 2 Feb.) NOTE: This success criterion can only be applied to non-web documents or software where the underlying platform permits a viewport size of 320 by 240 px or equivalent. WhenIf the non-web document or software does not support a viewport of this size, reflow is highly encouraged, but this SC cannot be applied, as written.
<PhilDay> AG WG rejected option 1. Option 0 is what is currently in the document
<PhilDay> Another edit on option 2 - to correct another typo
<PhilDay> Option 2: Phil’s 2024-02-2 from working session (formerly Option 7 as discussed on 2 Feb.) NOTE: This success criterion can only be applied to non-web documents or software where the underlying platform permits a viewport size of 320 by 240 px or equivalent. When the non-web document or software does not support a viewport of this size, reflow is highly encouraged, but this SC cannot be applied as written.
<PhilDay> PhilDay: prefer option 3 as it has more helpful info.
<PhilDay> bruce_bailey: Question on whether to separate out the small screen (watch) situation vs the large screen kiosk situation where you can address the need a different way <PhilDay> 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. ...
<PhilDay> ... 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 scrolling or reflow, ensure the user need is addressed by using sufficiently large text
<PhilDay> bruce_bailey: Option 0 addresses the AG question
<PhilDay> bruce_bailey: Then we can have an additional note providing this additional info.
<PhilDay> maryjom: Sam didn't want 'fail this SC' so other options were added
<PhilDay> Minor tweak to last sentence of Option 4. For systems that do not support zoom, scrolling, and reflow, ensure the user need is addressed by using sufficiently large text.
<PhilDay> maryjom: This is currently in main SC guidance. Should we put this in SC problematic for closed?
<PhilDay> For systems that do not support zoom, scrolling, and reflow, the user need is often addressed by other means (including but not limited to using sufficiently large text).
<PhilDay> Another attempt: For systems that do not support zoom, scrolling, and reflow, the user need is often addressed by other means (including but not limited to using sufficiently large text and single screen designs).
<bruce_bailey> +1
<PhilDay> For reference, here is the revised option 4 in full.
<PhilDay> 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. ...
<PhilDay> ... 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 limited to using sufficie
<PhilDay> ... sufficiently large text and single screen designs).
<bruce_bailey> +1 , the word "ensure" was giving me pause, and this addresses that
<PhilDay> Mary Jo to add text showing options 0 and 4 in a survey for full TF to review
SC Problematic for Closed Functionality: Keyboard-related SCs
SC problematic for closed / 2.1.4 Character key shortcuts
<maryjom> 2.1.4 Character key Shortcuts: w3c/
<bruce_bailey> +1 , no need for options 1-3 in survy
<PhilDay> PhilDay: Like Sam's proposal
<PhilDay> bruce_bailey: Also likes it
<PhilDay> maryjom: Next step - will present to wider TF for review
<bruce_bailey> +1 to take to group
SC problematic for closed / 2.4.7 Focus Visible
<maryjom> 2.4.7 Focus Visible: https://
<PhilDay> ption 1: As proposed in the December 2023 survey 2.4.7 Focus Visible - Requires a mode of operation where focus can be moved and controlled by keyboard. Some closed systems may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for focus; for example, the keys are used to select options from a spoken menu rather than to move an onscreen focus element between multiple options. In this case, th
<PhilDay> ... In this case, there is no concept of focus, and therefore there is no need for a visible indicator.
<PhilDay> Option 1+ Original proposal + edits: 2.4.7 Focus Visible - Requires a mode of operation enabling focus movement and control by keyboard. While certain closed systems may provide tactile input, like numeric keypads or other functional groups of keys, they lack a mechanism for traditional onscreen focus. ...
<PhilDay> ... For example, keys might be used to select options from a spoken menu rather than navigating an onscreen focus element between multiple options. In such cases, the absence of a conventional focus eliminates the need for a visible indicator.
<PhilDay> Option 2: to eliminate "requires mode of operation enabling ...control by keyboard This Success Criterion assumes there is a user interface component that receives keyboard focus. Menu-driven interfaces do not necessarily have visible components that receive focus, as they may have tactilely discernible input keys used to choose from a spoken menu of options. In such cases, there is no concept of focus or need for a visible focus indicator.
<PhilDay> Option 3: Add general guidance Note for 2.4.7 + bullet for SC problematic for closed General guidance note: NOTE: This criterion applies where there are user interface controls that are focusable using a keyboard interface. Some software may accept input from a keyboard, keypad, or controller, yet not display user interface controls; for example, the keys are mapped directly to functions without activating on-screen controls. ...
<PhilDay> ... In this case, there is no concept of focus and this criterion is satisfied.
<PhilDay> Option 3 continued: Bullet for SC problematic for closed: 2.4.7 Focus Visible - As noted in the section Applying SC 2.4.7 Focus Visible to Non-Web Documents and Software, when there are no on-screen controls this criterion is met.
<PhilDay> ... In addition, when a product with closed functionality has on-screen controls (for example, buttons on a touchscreen) and does not have a keyboard interface, there is no concept of keyboard focus and this criterion is met; however, as noted for 2.1.1 Keyboard it would need an alternate way to access all functionality.
<bruce_bailey> Are we approaching positive vs negative ?
<bruce_bailey> E.g., criterion applies where ... versus ... criterion is only applicable when
<bruce_bailey> w3c/
<PhilDay> Guidance added to issue #255: Approach guidance in SC problematic for closed as negative rather than positive 'criterion is only applicable when'
<PhilDay> w3c/
<bruce_bailey> i think 'criterion is only applicable when' is a better match to WCAG conformance model where not being applicable is 'meets'
<PhilDay> Modified Option 1+ Original proposal + edits: 2.4.7 Focus Visible - Requires a mode of operation enabling focus movement and control by keyboard. While certain closed systems may provide tactile input, like numeric keypads or other functional groups of keys, they lack a mechanism for traditional onscreen focus. For example, keys might be used to select options from a spoken menu rather than navigating an onscreen focus element between multiple options. ...
<PhilDay> In such cases, the absence of a conventional focus eliminates the need for a visible indicator and this criterion is satisfied.
<PhilDay> PhilDay: Shares maryjom's concern about having additional guidance in the SC may be an issue. Just adding a note to the SC problematic for closed makes more sense, in which case options 1 & 3 should be merged...
<PhilDay> Option 4: Bruce’s edit of Option 1 2.4.7 Focus Visible - Presumes that there is a mode of operation where focus can be moved and controlled by keyboard. Some closed systems may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for conveying focus because the UI is designed not to need that. ...
<PhilDay> ... For example, the keys are used to select options from a spoken menu rather than to move an onscreen focus element between multiple options. In this case, there is no concept of focus, and therefore there is no need for a visible indicator.
<PhilDay> Modification of option 4
<PhilDay> Option 4: Bruce’s edit of Option 1 2.4.7 Focus Visible - Presumes that there is a mode of operation where focus can be moved and controlled by keyboard. Some closed systems may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for conveying focus because the UI is designed not to need that. ...
<PhilDay> ... For example, the keys are used to select options from a spoken menu rather than to move an onscreen focus element between multiple options. In this case, there is no concept of focus, thus there is no need for a visible indicator and this Success Criterion would be satisfied.
<PhilDay> (Bruce's latest edits from the Google doc)
<PhilDay> Option 5 (edit of Option 1+ to remove Requires): 2.4.7 Focus Visible - Presumes that there is a mode of operation enabling focus movement and control by keyboard. While certain closed systems may provide tactile input, like numeric keypads or other functional groups of keys, they lack a mechanism for traditional onscreen focus. ...
<PhilDay> For example, keys might be used to select options from a spoken menu rather than navigating an onscreen focus element between multiple options. In such cases, the absence of a conventional focus eliminates the need for a visible indicator and this criterion would be satisfied.
<PhilDay> PhilDay: Prefer option 4 over option 5
<PhilDay> Propose that we take option 1 (original), and option 4 (Bruce's) and send to main TF in a survey
<PhilDay> maryjom: If you get a chance, take a look at No keyboard trap
<maryjom> 2.1.2 No Keyboard Trap
<maryjom> w3c/
<PhilDay> We may also need to look at keyboard operable to ensure consistency