WCAG2ICT Project: Update Success Criteria Problematic for Closed Functionality section

[maryjom]

• Complete the Closed functionality analysis spreadsheet
• Propose how we might better handle and characterize use of WCAG for Closed Functionality software. (e.g. should we incorporate notes into the individual SC sections, write clearer and more detailed information per SC on the many pitfalls or concerns over applying particular SCs to closed products, or write some position on this use case)

This needs to be carefully considered, as the EN 301 549 already applies most of the SC to closed products (or points to replacement requirements to address that user need). We don't want to cause further splintering and potential for non-harmonization, so there may need to be some more clarity on pitfalls for particular classes of closed products that could be incorporated into the standards.

• Analyze new SC for applicability, issues with use for software with closed functionality. We are mostly doing this as we work on the SC, but may want to quickly think about any other notes, if needed.
• Once proposal is accepted by the TF, incorporate changes into the document.

[pday1]

Notes going into Appendix A.

From March 23rd, 2022,
In Appendix A. Success Criteria Problematic for Closed Functionality add the following:

1.4.11 Non-text Contrast—There are cases where applying this SC to non-web software on closed functionality products is problematic:
Products where the appearance of non-text content is determined by the hardware and not modifiable by the author (rather than determined by a user agent or platform software); such products should meet the exception for this SC.
Products with no ability to programmatically determine the foreground and background colors used by the software. This means that precise quantifiable testing cannot be performed to ensure the contrast requirement has been met.

[maryjom]

What I hope to address with this issue is to see if any of the existing SC (from WCAG 2.0) could benefit from additional bullets, explanations, or guidance for closed functionality that are not already there. It seemed like the 2013 version glazed over things a bit more and I want another look at this.

[GreggVan]

We need to have a discussion about all of these closed product items. In none of them should we say that software or content (documents) qualify for an exception because the other software on the product does not meet basic ’user agent’ functionality. r That is like saying — "All videos qualify for an exception to captions because the video player on our closed product does not support captioning." In this case -(Below) all of the context needs to have text alternative — AND the software/hardware displaying the content need to display that text alternative. For closed products - the requirements are NOT LESS — they ARE MORE. - Closed products need to do everything that content needs to do AND they need to do everything that a good accessible user agent would do AND they need to do everything that Assistive technologies would do They need to do 1 and 2 because they are the content and the user agent. Then need to do #3 because they do not allow the connection of AT (so they can’t rely on AT to do that part of making things accessible.) Think about it and you will see the suggestions like below are upside down — and do not result in accessible closed products. [I am working on a new approach to accessibility that could help solve this problem — but for the next 5-10 years at least — this is the situation. Closed products need to do all the work themselves — or they are not accessible. The fact that it is harder does not mean that accessibility requirements are less. Just that it is much harder to make a closed product accessible. ] Best Gregg

…

On Mar 23, 2023, at 7:26 AM, Phil Day ***@***.***> wrote: Notes going into Appendix A. From March 23rd, 2022, In Appendix A. Success Criteria Problematic for Closed Functionality add the following: 1.4.11 Non-text Contrast <#44 (comment)>—There are cases where applying this SC to non-web software on closed functionality products is problematic: Products where the appearance of non-text content is determined by the hardware and not modifiable by the author (rather than determined by a user agent or platform software); such products should meet the exception for this SC. Products with no ability to programmatically determine the foreground and background colors used by the software. This means that precise quantifiable testing cannot be performed to ensure the contrast requirement has been met. — Reply to this email directly, view it on GitHub <#44 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXT44QUWFH54IMOC32TW5RMQVANCNFSM6AAAAAARPI2AM4>. You are receiving this because you are subscribed to this thread.

[samogami]

Responding to Gregg's comments:

We need to have a discussion about all of these closed product items.

Agreed. We are and continue to discuss problems with closed functionality in GitHub issues, surveys, and weekly TC calls.

In none of them should we say that software or content (documents) qualify for an exception because the other software on the product does not meet basic ’user agent’ functionality.

In your comment above, I assume that "none of them" means success criteria. I disagree that TC should not be open to providing success criteria exceptions and guidance when necessary. WCAG is and continues to be developed with a web-first perspective. The main reason for WCAG2ICT is to apply WCAG to ICT when appropriate. It is more than just replacing the word 'web' with non-web software and documents.
An example is the contrast of UI components or cursor focus if the user agent has made poor choices in contrast and the web author has not - even though it's sometimes programmatically possible to do so. Suppose someone is writing software for a closed product with a display that offers poor contrast without any programmatic ability to modify it. In that case, the closed product software itself cannot fix, modify, or otherwise improve the contrast. It can't be the software's responsibility to fix. There is already a hardware requirement (in 508 and EN 301 549) that closed products provide a basic level of contrast. If the display doesn't provide sufficient contrast, it would fail the hardware requirement. It shouldn't also fail the software requirement. The software did not cause the problem (there is no bug in the software to fix). The first note is to address this case.

That is like saying — "All videos qualify for an exception to captions because the video player on our closed product does not support captioning." In this case -(Below) all of the context needs to have text alternative — AND the software/hardware displaying the content need to display that text alternative.

WCAG is not the only standard that provides requirements for captioning. EN 301 549 and S508 provide captioning requirements provision 413.1. The video content creator would have to assume that the ICT is meeting the basic requirements for captioning processing and provide a type of captions supported by the technology they will reside on. However, if that content is rendered on a device that does not display those captions, it is not the content developer's fault but the responsibility of the developer of the device. Different people are creating different aspects of the closed product, you have to attribute the requirement to the right part of the closed product hardware, software, and content developer. To achieve better accessibility, all of the necessary parts have to have appropriate accessibility requirements and then meet them.

For closed products - the requirements are NOT LESS — they ARE MORE. - Closed products need to do everything that content needs to do AND they need to do everything that a good accessible user agent would do AND they need to do everything that Assistive technologies would do. They need to do 1 and 2 because they are the content and the user agent. Then need to do #3 because they do not allow the connection of AT (so they can’t rely on AT to do that part of making things accessible.)

Closed products do have many requirements, but WCAG is not the only standard (ATAG, UAAG, etc.). For closed products, there are additional applicable accessibility standards (S508, EN 310 549, etc.). Providing notes and sometimes exemptions enables manufacturers of closed products to create the best accessible products. WCAG2ICT without notes and exemptions will result in work to meet accessibility requirements that do not result in a more accessible product (see example above) and just add additional work. There are cases where WCAG criteria are not a 100% fit for all closed-product software.

[maryjom]

Wondering if this Closed Functionality analysis spreadsheet can help folks begin looking into the various SC, what the existing content for Closed Functionality is in the editor's draft and identifying where there may be a need for something more or different.

I think it might be helpful if we each complete the spreadsheet and send the analysis to me to collate and see where we have common ground and where work is needed.

Note, though we are focusing on Level A and AAA for this release of WCAG2ICT, I have listed Level AAA criteria are in a separate table in case you want to notate anything there. If you have limited time, just skip the Level AAA criteria.

[maryjom]

I've created a Google Sheets Closed functionality analysis spreadsheet per our 4 May meeting discussion.

[maryjom]

See PR #173 for initial proposed additions and changes. See also the survey on proposed changes to SC Problematic for Closed Functionality where TF participants are working to refine the changes.

Other issues will likely be spawned from this larger issue to tackle various topics, referenced below:

• Add "closed functionality" to Key Terms #203

[pday1]

• Add 2.5.8 Target Size (Minimum) to Success Criteria Problematic for Closed Functionality.

Proposed text:
2.5.8 Target Size (Minimum) - requires use of CSS pixels. Closed functionality may not use CSS pixels. If the system supports device-independent pixels, these should be used in place of CSS pixels. Otherwise, a physical size fallback based on the research for fingertip size could be developed by a standards organization.

New content has been created, and is now tracked in separate issue #293

[mitchellevan]

Hi @pday1, I just submitted a long comment here... But now I've deleted it here, because you mostly covered what I was looking for already in your discussion under #258. My mistake! I'll read #258 properly and I'll add my comment there instead.

[pday1]

Issue #271 contains a proposal for adding a bullet for SC 2.4.7 Focus Visible.

[maryjom]

Based on surveys, we had opened several issues to individually develop and track the guidance for each SC problematic for closed functionality as well as updates to the "Comments on Closed Functionality" section. Will leave this as the only open issue to track to the point where the AG WG to reviews the content changed so we can get a better picture of what work is left to be done.

Out of the issues we've opened, the group reached consensus on SC bullets introduced using issues: #270, 271, 272, 273, 275, 293, and 315. I've closed those individual issues where the content has been incorporated into the latest editor's draft.

[maryjom]

All content for this section is now in the document as of 16 May and this section is undergoing AG WG review (See issue #370). Any further updates/comments will be addressed using the AG WG review or a new issue.