Approach to updating Appendix A: Success Criteria Problematic for Closed Functionality

[maryjom]

Since we didn't really come to a conclusion on the approach during the 13 April call, I'm opening this discussion thread so you can post your ideas on breaking the work into manageable chunks, as well as the analysis needed.

Some ideas are:

• Work on groups of SC splitting by guideline categories in WCAG
• Divide by assistive technology (so you think about tech closed to that technology, and then go through all of the SC to figure out which SC would need guidance).
• A combination of the two. When you take up a guideline category, you analyze for each AT category.

Questions:

1. Can you think of a preferred or better method of splitting the work?
2. What AT categories are important to consider in the analysis? (e.g. products that are closed to keyboard alternatives, products that are closed to screen readers, etc.)
3. Do we need to have a list of tech/use cases or categories of closed functionality products to think about for each grouping (e.g. printers, ATMs, very small iOT devices, electronic signs, etc.) If so, what would you add to that list?

[GreggVan]

I don't think we should be looking at any particular SC by AT.
This would be backward looking and prone to bias. First - which of the different AT that exist are we going to examine. I'm not sure I know of all of the current types. If a product is closed, then the only way to have equivalent accessibility is for the product to build in all AT for all types, degrees and combinations of disability. I don't know what those are.

Second, what about future types. There are AT for cognitive, language, and learning disabilities that will be available soon, 3-5 years. how do we list the ways those need to be met.

I think that we should instead have a long discussion about the issue as a whole. Probably a whole meeting -- maybe multiple. We need to figure out how to even approach this problem. No one else has to date. Mostly current accessibility guidelines just look at one or to disabilities and one or two types of access/AT. And then the provided the most basic versions of those and ignored the rest.

Short list of people cut off by closed products
People who....

• are blind (with and without cognitive disabilities) (with an without physical disabilities e.g. gestures and fine motor and reach)
• have low vision (with and without cognitive disabilities) (with an without physical disabilities)
• have very low vision (with and without cognitive disabilities) (with an without physical disabilities)
• have physical disabilities
• are hard of hearing or deaf (with and without low vision / no vision) (with and without physical disabilities)
• have cognitive, language, and learning disabilities (with and without vision, hearing, and physical disabilities)
  --- of all types and there are many

Closed products cut off all use of AT so the question is -- if we cut off all AT what are we going to say about the responsibility of the closed products to make up for it. I see two choices - neither of which is acceptable/reasonable (hence I think we need a long discussion -- maybe too long.. but we should at least take a stab at it before we write the Closed Product section

1. we just say companies need to build in a couple AT -- and everyone else just loses access
2. we say that companies need to build in all AT that was available to products that are not closed -- and give companies an impossible / impractical solution.

there is a third option
3) create AT that work on closed products (kind of a contradiction) but I mention it because it is in fact what I am proposing we do because 1) the problem and unacceptable options above and 2) I think we will (with a lot of R&D ) be able to do that in the near future. See https://futureofinterface.org -- and more specifically https://futureofinterface.org/auditorium_cpt/alternate-visions-for-accessibility-in-future/

[mraccess77]

@GreggVan I think this is where we try to cover/map to the user needs/functional performance criteria and keep those as wide as possible in the near time. In the future there would be some sort of secure method to allow for transformation.

[maryjom]

In this exercise we are not trying to "boil the ocean" of solving all current and future accessibility issues on closed functionality products for all current and future AT. We are simply trying to point out where some of the existing WCAG SC are built on the assumption that there is AT available to use programmatic information, settings to increase font sizes, sufficient memory and processor power to address all of the user needs in all types of closed functionality products. The assumption of ability of all closed functionality products to directly support every potential user need is something that is simply not present on all closed functionality products. Addressing shortfalls in alternative closed functionality requirements for non-web software to meet all of the Functional Performance Criteria is not within the scope of our work. Recommendations to use functional performance criteria instead is also out of scope for our TF.

This discussion is only regarding what I thought was said in the TF meeting that we should look into the way the EN handled things - e.g. keyboard requirements, they looked into when keyboards and keyboard alternatives are not available, then what does that mean for the requirement. In that instance, they created alternative requirements. If we point out where WCAG criteria aren't a good fit, then the other standards organizations can better understand where work might be needed to explore the various user needs and develop necessary requirements to fill any gaps that exist. It isn't in our TF's scope of work to address those things.