Meeting minutes
Zoom link is at https://
agenda
Issue 216 - worth looking at
Public comments
Public comments - list is getting smaller
<maryjom> w3c/
226
<maryjom> w3c/
In AGWG, Mary Jo proposed a change which may not have been seen by the whole WCAG2ICT task force.
Question from AGWG was from Detlev, specific to 1.4.10 - what does 'may not be possible' mean?
… That is where the wording "when it is not possible to meet the SC then you automatically fail the SC"
Sam: In other areas we don't automatically say you fail the SC - we use softer language (e.g. name role value, helps to meet the intent)
maryjom: This specific comment was about Reflow
<Chuck> This success criterion may not be applicable for technologies and platforms that do not support reflow.
maryjom: Alternative may be to handle those cases and add some exception if system is not capable of supporting reflow
<maryjom> Reflow has exception: Except for parts of the content which require two-dimensional layout for usage or meaning.
Chuck: Has proposed some alt language that is not in the issue. Agree if you cannot meet it, valid interpretation that you don't fail.
… However, if device does not support zoom, there is no need for reflow, but pass seems too strong, maybe suggest not applicable.
Sam: We avoided not applicable in the past
mitch11: Can use it - but clarify that not applicable is a pass
maryjom: Using not applicable is difficult for some to accept - looks to some like we are opening a potential loophole
<Chuck> WCAG 2 conformance: However, if the page does not conform to WCAG only for reasons that are legitimately outside the author's control then the author can make a claim of partial conformance.
mitch11: May help to give more concrete examples of systems where reflow is not appropriate, and therefore exceptions are allowed, as opposed to mobile apps
<Chuck> Note: This means that if there is no content to which a success criterion applies, the success criterion is satisfied.
Sam: Examples include systems for public use, or shared usage. Also those in physical environment where people can move closer/further away. Also very small displays.
mitch11: Also includes very large information boards (touchscreens).
<Chuck> If the content and technology and platform software do not support reflow, this is outside of the author's control, and the author can make a claim of partial conformance.
Chuck: suggesting possible ideas to tweak the language
<Chuck> If the content technology and platform software does not support reflow, then there is no content to which this success criterion applies, and the success criterion is satisfied.
<Chuck> If the content technology or the platform software does not support reflow, then there is no content to which this success criterion applies, and the success criterion is satisfied.
This is the language for reflow from problematic for closed: 1.4.10 Reflow — Many closed functionality products do not allow users to modify the viewport or change font sizes, so there would be no need to impose a requirement on all closed functionality that content is able to reflow. Additionally, many closed functionality products do not display large chunks of text and only have UI controls; in such cases, two-directional scrolling to ac[CUT]
… controls; in such cases, two-directional scrolling to access the text and UI controls may be considered essential. <END OF QUOTE>
mitch11: We could have a type of closed; systems closed to reflow
<Chuck> If the content technology or the platform software does not support reflow, then there is no content to which this success criterion applies, and the success criterion is satisfied.
<mitch11> We could say: If the platform doesn't allow reflow, we could say the software is closed to reflow, which is a case of closed functionality
Chuck: agrees that calling this a failure seems wrong.
mitch11: Brief discussion on how to handle VR - we'll leave that for another time!
Sam: If signage was for public safety, wouldn't want truncation due to reflow, so this would be an essential exception
Chuck: 2 potential rationale.
… 1) system is closed to reflow
… 2) exception is essential
maryjom: Could combine: if certain type of presentation is essential, then is closed to reflow
Sam: If closed, you can't apply additional assistive tech. If shared environment, don't think there is a way of doing it - so would fall into closed functionality bullet
Sam: Open system, you could add AT to provide reflow
<Chuck> Definition of essential: if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform
mitch11: Staying within general topic. Essential exception: best applied to content of software, rather than to the platform/architecture
… We can list exceptions for content, but wonder if we can do this for platform.
… If we call it closed, is this due to the platform, or due to other reasons?
maryjom: That might help for other questions - further discussion about reflow where size of CSS pixel window is not possible. We say use closest possible, then others have replied that it makes it meaningless.
… However, not all tech can support that window size
mitch11: That is a good case to mention then - it is a concrete example
<Chuck> example of closed functionality from our own draft: an ebook or ebook reader program that allows assistive technologies to access all of the user interface controls of the ebook program (open functionality) but does not allow the assistive technologies to access the actual content of book (closed functionality).
mitch11: Maybe have to say something like "if platform is closed to providing 320x320 CSS pixels or equivalent" then it is closed to this requirement of reflow
Chuck: mentioning ebook / reader example from closed functionality draft. You can't resize the viewport, so this is again a good example, and again shows why we should use the closed argument
… Essential seems harder to justify
… Closed seems a more solid rationale
mitch11: Using Mac as an example, some apps are designed for full screen usage, and cannot be sized down to 320x, but not sure why this is essential. Makes more sense to say system is closed to this functionality
Sam: What about systems where viewing distance changes?
… Again this may not be possible or desirable - if viewing distance is unknown
… Agree with Chuck on ebook reader as a good example.
maryjom: Maybe differentiate between principle of reflow (which is useful), without getting hung up on specific CSS pixel sizes
Use case is zooming in for low vision, then if viewport limits you so you have to constantly scroll badly. That is where reflow is important
Another use case - messages on a smart watch
mitch11: Another example: email - sometimes reflow works, other times it doesn't
mitch11: Typing a proposal...
<mitch11> I propose something like this: where the platform is closed to presenting content in a 320 equivalent viewport, it is a best practice nevertheless to reflow text
<maryjom> WCAG's note: 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% zoom.
closed functionality products do not allow users to modify the viewport or change font sizes
Full text https://
Many closed functionality products do not allow users to modify the viewport or change font sizes, so there would be no need to impose a requirement on all closed functionality that content is able to reflow.
Additionally, many closed functionality products do not display large chunks of text and only have UI controls; in such cases, two-directional scrolling to access the text and UI controls may be considered essential.
Agreed direction for reflow - mention closed and point to the bullet above
maryjom: Will open Google Doc to work on some language around this.
<Chuck> Additionally, many closed functionality products do not support changes to viewport size or font size; in such cases...
<Chuck> Additionally, many closed functionality products do not support changes to viewport size or font size to 400%; in such cases...
maryjom: Reflow - have language that reflow is desirable. If tech does not allow a specific viewport size or change font size, it would be an essential exception. But best practice is to provide reflow
<mitch11> in such cases, the non-web content is closed to small viewports - see x.x.x Reflow in "Problematic for Closed Functionality"
<Chuck> Additionally, many closed functionality products do not support changes to viewport size or font size to 400%; in such cases the presentation of content by the closed functionality product would be deemed essential.
maryjom: Will circulate the Google Doc with the minutes.
… If you have an issue assigned, please propose content. If you have any spare time, assign yourself to an issue and add content.