- From: Gregg Vanderheiden RTF <gregg@raisingthefloor.org>
- Date: Mon, 3 Oct 2022 23:11:18 -0700
- To: Mary Jo Mueller <maryjom@us.ibm.com>
- Cc: "public-wcag2ict-tf@w3.org" <public-wcag2ict-tf@w3.org>
- Message-Id: <74B4E2C2-3D35-44AE-A3D1-241D09D40824@raisingthefloor.org>
Very interesting question. I think it better to keep it as ICT in the name. Then in the document itself we can talk about where WCAG is and is not appropriate RATIONALE: (some of this you already listed below) Continuity of name Continuity of approach (the old one used ICT and then defined where it did and did not apply) Easier to use broad term and then limit inside than to have a very long name describing all the places that it does apply Non-web content (e-documents) Any software with a user interface. This includes apps but also server software and operating systems and many other types of software that have user interfaces - that need to be accessible. We explain that it applies to the user interface portion of software — but not the rest - though again we can do that in the document but not in the title very well. RE the BIOS — we should not get into that. We define where it can be applied to make interfaces accessible. But we don’t require it be used ANYWHERE It would be policy group that says that it does not need to apply to BIOS (though we can mention the problem there in our doc) But what is really being said is that the BIOS does not need to be accessible ALSO I note that some computers provide a GUI that runs in the OS when booted - that can be used to adjust the BIOS on next boot. So in that case it would apply to code that adjusts the BIOS — just not the interface on the boot time code of the BIOS. > On Oct 3, 2022, at 6:39 PM, Mary Jo Mueller <maryjom@us.ibm.com> wrote: > > Definition of non-web ICT covered by the WCAG2ICT Note. Previous discussion on possibly changing “non-web ICT” to “non-web documents and software” (contributed by Bruce) or “non-web documents and application software” (contributed by Sam). The discussion on 22 September seemed to go in the direction of NOT changing the term (and thus the long-used title of the WCAG2ICT document) into the direction of either using the existing definition in the Note, or some variation of that, in the work statement’s scope. The text from the WCAG2ICT Note has two related bullets that read: > Because this document deals with applying WCAG, which is a standard for web content accessibility, to ICT it does not deal with such things as closed products and requirements for non-user interface aspects of platforms, nor individual components. As such, this document is not sufficient by itself to ensure accessibility in non-web documents and software. > This document does not comment on hardware aspects of products, non-user interface aspects of platforms, or user-interface components as individual items, because the basic constructs on which WCAG 2.0 is built do not apply to these. > > It is my understanding that many of the difficulties lie in the fact that low-level software (e.g. BIOS) that is run before AT can be initiated and other software that provides a basic UI on hardware (e.g. on closed products where AT cannot be installed). The original WCAG2ICT did make simple statements about some problematic success criteria for products with closed functionality. > > Did I characterize this correctly? If someone can describe this better, please comment. > > Can we add a statement to the out-of-scope bullets such as: > > Applying WCAG to hardware aspects of products, non-user interface aspects of platforms, or user-interface components as individual items, because the basic constructs on which WCAG 2.0 is built do not apply to these. > > Would this be sufficient? Please weigh in and offer alternatives, if needed.
Received on Tuesday, 4 October 2022 06:11:32 UTC