Where a technology does not support an SC

[melaniephilipp]

In general, where the content technology or platform software do not support a Success Criterion, when evaluating authored content for that platform, the SC should be considered Not Applicable (as opposed to Failed) as it is out of the hands of the content author. In other words, the content technology or platform software would Fail the SC, but for content authored to be used on the technology or platform software the SC would be considered Not Applicable or not in scope.

For example, 1.4.10 Reflow asks the question in the Editor’s notes: “Are there situations where the content technology and/or platform software do not support reflow? If there are, please explain and indicate whether applications built for this environment should fail this criteria or have an exception so that this requirement doesn't get applied.”

The current 1.4.10 Reflow, Note 6 says: “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.”

I recommend changing the end to “...meaning this Success Criterion would not apply to the software application.”

[maryjom]

Thank you for taking the time to review the WCAG2ICT public draft. Our task force will review your comment and develop a response that we hope will address your concern. The response will be drafted in a comment on this issue, marked DRAFT RESPONSE until the Task Force reaches consensus.

[Lboniello]

DRAFT RESPONSE: In other similar instances, we have handled such criteria by failing the application and leaving exceptions to outside policies/laws to address. It is largely believed that allowing for "can not be applied" would provide opportunities to disregard this criteria more broadly.

[maryjom]

TASK FORCE RESPONSE: In other similar instances, we have handled such criteria by failing the application and leaving exceptions to outside policies/laws to address. It is largely believed that allowing for "can not be applied" would provide opportunities to disregard this criteria more broadly. Additionally, per list item 2 in the Comments on Conformance, "Not applicable" is used in cases where content relevant to the requirement does not exist for the Success Criterion being evaluated, and would automatically be a "pass" or "meets" the Success Criterion. When a technology does not support a particular Success Criterion, however, it should not necessarily automatically pass it.

As an example, one could create a new PDF replacement that does not support accessibility at all. Then anyone using that inaccessible PDF replacement would automatically pass WCAG because the technology doesn't support accessibility at all. If a technology doesn't support a success criterion -- then anything made with that technology will (and should) fail that success criterion.

[GreggVan]

agree -- only suggest that we add a "however" in after last "Criterion" (Criterion, however...)
we might also add for clarity " Otherwise it would mean that one could create a new PDF replacement for example, that does not support accessibility at all . Then anyone using that inaccessible PDF replacement would automatically pass WCAG because the technology doesn't support accessibility at all. If a technology doesn't support a success criterion -- then anything made with that technology will (and should) fail that success criterion. "

the example makes it longer - but makes it much clearer what "broader exception" means - since the author clearly didn't think of this - as many don't when they suggest this.

best

[maryjom]

@GreggVan Thanks for your input. I've updated the answer above.

[alastc]

Is it worth differentiating situations where the physics might be the main factor?

e.g. If something has a smaller screen than 320px? Or where you can vary your viewing distance (such as a very large screen you can walk up to).

I agree with the point about creating loopholes for current or future technologies, but perhaps we should acknowledge more extreme physical situations?

E.g.

This applies directly as written... except when the platform is within physical constraints that make it impossible to achieve. For example, the viewport is smaller than the minimums, or it is a public display where people can choose to stand very close to a very large display.

[WayneEDick]

When a technology does not support a Success Criterion the SC is not evaluated for that technology. The technology is accessible to people who need that SC. Because 1.4.10 is so important for people with central retina damage, technologies that do not support it are not accessible for people with central retina damage. Development on such technology is exempt from conformance. However, a public institution that uses this technology will deny access to information for a large well defined group of people with disabilities. The information should be available in an alternative technology if the institution cares to be inclusive. Failure to do this may not be illegal, but it is profoundly unethical.

On Fri, Sep 29, 2023 at 7:42 AM melaniephilipp @.***> wrote:

In general, where the content technology or platform software do not support a Success Criterion, when evaluating authored content for that platform, the SC should be considered Not Applicable (as opposed to Failed) as it is out of the hands of the content author. In other words, the content technology or platform software would Fail the SC, but for content authored to be used on the technology or platform software the SC would be considered Not Applicable or not in scope.

For example, 1.4.10 Reflow asks the question in the Editor’s notes: “Are there situations where the content technology and/or platform software do not support reflow? If there are, please explain and indicate whether applications built for this environment should fail this criteria or have an exception so that this requirement doesn't get applied.”

The current 1.4.10 Reflow, Note 6 says: “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.”

I recommend changing the end to “...meaning this Success Criterion would not apply to the software application.”

— Reply to this email directly, view it on GitHub https://github.com/w3c/wcag2ict/issues/226, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6Q4FZLYSWA5QT3QVVRVM3X43M4JANCNFSM6AAAAAA5MSO2KE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[maryjom]

WCAG2ICT is not really at liberty to provide normative language on where an SC would or wouldn't apply (it's not in our defined scope of work). We can, however, point out where this can pose difficulties for non-web ICT. For example, in the SC problematic for closed functionality section. That is the type of topic where we've been documenting that there might be technologies with really small screens, limited functionality that a user cannot adjust the font size or viewport size. Where there is a minimum text size required (due to closed functionality requirements posed by 508 and the EN 301 549) which may, in fact, cause scrolling in 2 directions to view menus (e.g. On a printer, one might have to scroll right to read an entire menu item or entry field, and then scroll down to read the next menu item or other control). Technically, if you strictly apply the 1.4.10 Reflow to any size screen, this would not meet the SC, though one could argue that it is accessible. It isn't like trying to read a book or a paragraph of text where it is understandably difficult to follow contiguous text that scrolls in 2 directions.

[mraccess77]

My two cents - my Apple watch has a really small screen and does support some resize and reflow of text in apps like email, text messages, etc.

Separately, if you had menu items where each menu item was on a line by itself and it required horizontal scrolling to read the whole menu item then I would consider that it meets the SC as you don't have to scroll in two directions to access that content - but perhaps others don't read it that way.

[mraccess77]

I believe the visual degree anchor will help with situations where devices are meant to be held up close vs. far away. That will allow it to be flexible based on context.

[GreggVan]

My two cents - my Apple watch has a really small screen and does support some resize and reflow of text in apps like email, text messages, etc.

Separately, if you had menu items where each menu item was on a line by itself and it required horizontal scrolling to read the whole menu item then I would consider that it meets the SC as you don't have to scroll in two directions to access that content - but perhaps others don't read it that way.

This would fail. You need to scroll horizontally to read the items and vertically to read the list. The same problem exists for finding the next item as for finding the next line in a paragraph. The items on your watch should word wrap. (Don't they now?)

[mraccess77]

Items on the Apple watch can wrap in list form. I was primarily thinking of things that you didn't need to scroll vertically to understand their relationship. For example, a horizontal scrolling video widget where the videos for that section only appear horizontally - but I agree if you need to know the association between items then you shouldn't have to scroll in two dimensions.

[patrickhlauke]

I believe the visual degree anchor will help with situations where devices are meant to be held up close vs. far away

we couldn't anchor certain SCs, like touch target on visual angle for web content, because this is completely outside of the knowledge/control of authors (as it then relies on knowing the actual viewing distance, actual physical dimension of a display, and the resolution that display is running). the same way they couldn't be anchored on "as measured on screen" physical dimensions, for the same reason (authors can't know the actual physical dimension of the screen, nor what resolution it's running). which is why we anchored things purely on CSS pixel (with the exception of that definition for flash threshold, which - as we've already discussed separately - becomes completely meaningless / not author-controllable once applied to responsive design scenarios, and devices with different screen sizes and viewing distances.

not sure how for non-web ICT the situation will be easier to define in more absolute physical measures, unless it's done specifically for very controlled environments where authors can be certain of physical sizes/viewing distances/resolutions/etc

[maryjom]

With this issue included, there's 5 separate issues where reflow is being discussed as either a main topic or side topic along with CSS pixels as it relates to this Reflow and Target Size. Here's a list of the WCAG2ICT issues where the 1.4.10 Reflow issue is specifically being addressed: #257, #221, as well as issues regarding CSS pixels #200 and #227. When there's conversations being repeated or nuanced in different places, it is increasing the difficulty for me to come to a good understanding of different viewpoints, propose potential changes, and come to consensus on 1.4.10 Reflow and CSS pixels questions. I would prefer those conversations NOT take place in this issue.

To take this particular issue back to the original question being asked. The ask was what to do when a technology doesn't support an SC - how should you answer? This is the WCAG2ICT TF answer to that particular question. If folks have questions regarding that answer, please let us understand your concern.

I will avoid further addressing any rabbit-hole discussions about public policy, legacy products, 1.4.10 Reflow etc. here. New topics should have their own new issue opened (if needed), and additional information on reflow should be discussed in the more specific issue(s) opened for that SC. I appreciate everyone's conversation but want to help us stay focused so that specific issues can be answered and closed instead of become an endless continuum of new topics.

[samogami]

@maryjom Does that mean that when it is not possible to meet the SC then it you automatically fail the SC. That does not seem right. It is depended to the situation. If the SC is a fail or not applicable. See Comments on Conformance. The sentence below should remove part about failure as it depends.

“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."

Change to:

"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. "

[maryjom]

@samogami This text was added in an attempt to address Detlev's comment in the AG WG review of the addition of 1.4.10 Reflow. See the survey results for 1.4.10 Reflow and the conversation about this in the AG WG meeting that followed. I believe I had proposed we simply say the SC fails (in PR 199) to attempt to address Detlev's concern. Since WCAG doesn't have a N/A status and N/A is a "pass" per WCAG conformance, it's odd to say this SC is not applicable. The AG WG was OK with publishing with this verbiage, as long as there were editors' notes to ask for more scrutiny. But I do believe we will need to nail this down before publishing again.

Perhaps an alternate way to handle it is to claim that this would be a case where the software would meet the exception because its underlying platform or technology is not capable of supporting reflow.

[maryjom]

Updated WCAG2ICT TF answer:

When a content technology does not support a particular Success Criterion, it should not necessarily automatically pass it. As an example, one could create a new PDF replacement that does not support accessibility at all. Then anyone using that inaccessible PDF replacement could argue that it should automatically pass WCAG because the technology doesn't support accessibility. We do not agree with this argument. If a technology does not allow authors to create conforming content, and a WCAG criterion does not provide an exemption, then anything made with that technology will (and should) fail that success criterion.

Parts of the normative language of SC 1.4.10 Reflow are written in a technology-specific way. The phrases “at a width equivalent to 320 CSS pixels” and “at a height equivalent to 256 CSS pixels” combine two things: first, a presumption of a precondition always met by the content technology (the ability of the user agent to display content at a viewport dimension); second, a success condition of the criterion (the ability of the content to adapt to a viewport dimension).

Due to numerous comments on 1.4.10 Reflow, the Task Force re-examined the guidance in the Applying SC 1.4.10 Reflow to Non-Web Documents and Software section. We took into consideration various scenarios including:

1. There may not be any scrollable content - as is found in ICT with closed functionality which is designed to have limited content on each screen. This situation would automatically pass the success criterion.
2. The platform and/or user agent does not have a testable viewport with the exact scrollable dimensions specified by WCAG (multiple examples such as tablet with side-by-side browser windows, small screen devices - mobile or otherwise, etc.).
3. There may be no platform and/or user agent capability for adjusting the font size.
4. There may be a menu-driven interface where there are no blocks of text to read (E.g. a basic printer’s control panel.)

We have modified the notes (what was previously Notes 6 and 7 in the FPWD) to instead say:

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 256 CSS pixels for horizontal scrolling content.

When the underlying user agent or platform does not support these dimensions for scrolling, reflow is encouraged as this capability is important to persons with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.

We believe this change helps explain what to do in a situation where the platform or technology doesn’t support the WCAG criterion at least until it is clarified in the WCAG Understanding document.

[maryjom]

Closing as answered. If there's still a concern, either reopen this issue or a new one.