This survey is about bullets aimed for the SC Problematic for Closed Functionality section. In the 7 September meeting, the group discussed 2.1.1 Keyboard and we worked on various ideas for changing the proposal. The 3 options below are variations on what we discussed. Indicate which is your preference, and indicate any language tweaks or suggestions in the entry field below.

Option 1:

2.1.1 Keyboard — Requires operation via a keyboard interface which allows alternative input devices. The intent of this success criterion is to provide a means for people who have difficulty with quick and accurate pointing and path-based movements (for example, actions used to operate a mouse) to operate all the available functionality. Many closed functionality products do not have a keyboard or have a partial keyboard, such as a numeric keypad. For accessibility, functions are made available using tactilely discernable buttons or fulfill this requirement through alternate means that addresses the intent of this success criterion.

Option 2:

2.1.1 Keyboard — Requires operation via a keyboard interface which allows alternative input devices. This applies to systems with closed functionality that have a physical keyboard or a connector for standard keyboards. However, many closed functionality products do not have a keyboard or have a partial keyboard, such as a numeric keypad; in such cases, functions are often made available using tactilely discernable buttons or fulfill this requirement through alternate means that are covered by specific requirements intended for closed functionality products.

Option 3:

2.1.1 Keyboard — Requires operation via a keyboard interface which allows alternative input devices. When a closed functionality product either does not have a standard keyboard or one cannot be connected, it would need an alternate way to access all functionality that does not require accurate pointing, path-based movements, or specific timings.

Summary

Details

The Task Force discussed 2.4.2 Page Titled in the meeting on the 28 September. We were getting closer to consensus on edits to the proposed bullet but ran out of time. Based on the conversation and input received from the previous survey there are two new options for the bullet. Indicate which is your preference, and indicate any language tweaks or suggestions in the entry field below.

Option 1:

2.4.2 Page Titled — Where software is an integral part of hardware that provides a single function, such as a self-service transaction machine, calculator or IP telephone, there is no need for a title.

Background for Option 2

Notes on origin of "menu-driven interface": As an FYI, this term, as used in the proposal below, comes from the Wikipedia categorization included in the system software: user interfaces page.

menu-driven interface (quoted from Wikipedia) A menu-driven interface is commonly used on cash machines (also known as automated teller machines, or ATMs), ticket machines and information kiosks (for example in a museum). Menu-driven interfaces provide a simple and an easy to use interface composed of a series of menus and sub-menus which the user accesses by pressing buttons, often on a touch-screen device.

Option 2:

2.4.2 Page Titled — Where the software is part of a product that provides a single function, or has a menu-driven interface, there is no need for a title.

Examples: An example of a single-function product is a calculator. Examples of products with a menu-driven interface include: printers, self-service transaction machines and IP telephones.

Summary

Details

If Option 2 is chosen above, here is a proposed definition to include in the Key Terms section:

The term menu-driven interface, as used in WCAG2ICT, has the meaning below:

menu-driven interface (as used in WCAG2ICT)

a simple and easy-to-use interface composed of menus and sub-menus which the user accesses by pressing buttons or using a touch-screen

Examples: Products that have a menu-driven interface include, but are not limited to, self-service transaction machines, printers, and IP-based telephones.

Summary

Details

The SC 2.4.5 Multiple Ways was previously surveyed and based on survey results there was an editorial change, shown below. There was also a response to remove the bullet, but in an earlier conversation regarding these "sets of" criteria, the TF agreed we should at least mention these SCs are also problematic for closed functionality and either we should reiterate or point to notes in the main guidance supporting the rationale. Please review the edited text, indicate your preference and provide any proposed edits in the text field.

Proposal:

2.4.5 Multiple Ways—The WCAG2ICT interpretation of this Success Criterion replaces "set of Web pages" with "set of software programs" which are extremely rare - especially for closed functionality software. There are a number of notes in the section Guidance When Applying Success Criterion 2.4.5 to Non-Web Documents and Software that are applicable to closed functionality software.

Summary

Details