- From: Greg Lowney <gcl-0039@access-research.org>
- Date: Wed, 10 Jun 2009 23:42:49 -0800
- To: w3c-wai-ua@w3.org
- Message-ID: <4A30B579.3070302@access-research.org>
Some comments on proposed wording of the proposed 4.5 from UAWG Survey for 28 May (http://www.w3.org/2002/09/wbs/36791/20090527/results), "Guideline 4.5 Configure and Store accessibility preference settings". I will paste these into the survey form as well. 1. *(Re 4.5.1, Reconfigure accessibility defaults) Clarify defaults or delete:* What are "defaults", as opposed to a persistent user-preference setting that are already discussed in other SC in this section? Unless that can be clarified I can't see the value in keeping this SC. 2. *(Re 4.5.1, Reconfigure accessibility defaults) Change to standard wording: *A large number of SC that are worded in the form of "The user has the option to", and this could be rewritten in that format, e.g. "_The user has the option to_" change settings that impact accessibility. 3. *(Re 4.5.2, Save accessibility settings) Should everything be persistent**: *has no equivalent in ISO 9241-171 because we (ISO working group) left it up to the software developer to determine which user-adjusted settings are appropriate to be persistent across sessions and which are not. Some things should certainly be persistent, but we were not able to write up a specification to clearly identify which. Is it appropriate to make everything persistent when limited to user agents? Is that safe? 4. *(Re 4.5.2, Save accessibility settings) **Add ability to restore default settings: *See my previous comment "#81. (Re 4.5.1) Add ability to restore default settings: Please add a requirement that the user be able to restore user agent preference settings to their default values. Without that, if a user makes a change that is detrimental, 4.5.1 ensures that it will be difficult to get rid of. I would like to see this be Level A, although if too few user agents currently provide this then it could be Level AA for the time being. (Priority: 2 Medium)." 5. *(Re 4.5.3, Accessibility User Profiles) Harmonize with ISO:* 4.5.3 is equivalent to ISO's 8.2.5 (Provide user-preference profiles), so let's adopt or adapt their wording if possible (see below). 6. *(Re 4.5.3, Accessibility User Profiles) Remove 'Accessibility' from title: *If 4.5.3 is not replaced, rewrite to remove conflict between the title, which implies it's only about accessibility settings, and the body which is more general (e.g. by either removing the word "accessibility" from the title or adding it to the body). 7. *(Re 4.5.4, Accessibility Portable Profiles) Harmonize with ISO: *4.5.4* *is equivalent to ISO's 8.2.6 (Provide capability to use preference settings across locations), so let's adopt or adapt their wording if possible (see below). 8. *(Re 4.5.4, Accessibility User Profiles) Remove 'Accessibility' from title:* If 4.5.4 is not replaced, rewrite to remove conflict between the title, which implies it's only about accessibility settings, and the body which is more general (e.g. by either removing the word "accessibility" from the title or adding it to the body). 9. *(Re 4.5.5, Preference Wizard)** Clarify the term 'Wizard':* Note my earlier comment " #86. (Re 4.5.3) Clarify the term "wizard": The term "wizard" only occurs in this SC's title and text, and in the latter it's written in quotation marks. I recommend adding a definition of 'wizard' to the glossary and using it without quotation marks. (Priority: 3 Low)". 10. *(Re 4.5.5, Preference Wizard)** Change to standard wording: *A large number of SC that are worded in the form of "The user has the option to", and this could be rewritten in that format, e.g. "_The user has the option to_ access a wizard that helps them configure..." 11. *(Re 4.5, Store preference Settings) Someday delete section: *Section 4.5* *is entirely general software accessibility guidelines. As of these SC are specific to Web functionality, I hope they will be removed from future versions or drafts of the UAAG. Here are the relevant entries from ISO 9241-171 ("Ergonomics of human-system interaction -- Part 171: Guidance on software accessibility"): *8.2 User preference settings* * 8.2.1 Enable individualization of user-preference settings [ANSI Level 2]* When the software enables the user to set personal preferences, these settings should be easily adjustable. EXAMPLE 1 A software application allows users to configure and save settings for font size and style within a particular window. NOTE 1 System-wide user preference settings provided by the platform need to be used in addition to any preference settings for product-specific options. EXAMPLE 2 A software application allows a user with cognitive disabilities to choose the number and size of icons displayed at any one time. NOTE 2 Requiring users to hand edit a configuration file is not an easy method for individualizing preference settings because it is too easy for the user to accidentally enter invalid values or otherwise corrupt the file. EXAMPLE 3 A user chooses preference settings through a graphical user interface, rather than directly editing the configuration files. NOTE 3 Business considerations related to consistency of operations, performance-based considerations, safety, privacy, and security concerns can all lead to some necessary restriction by system administrators of the user's capability to modify the behaviour and appearance of user-interface elements in certain contexts. Administrators need to show restraint in limiting user control. Not all options/preferences settings are appropriate for such administrative control. NOTE 4 Administrators within this business environment can make specific permission profiles for users that require more flexibility in their options/preference settings for usability and accessibility. * * *8.2.5 Provide user-preference profiles [ANSI Level 3]* Software should enable users to create, save, edit and recall profiles of preference settings, including input and output characteristics, without having to carry out any restart that would cause a change of state or data. NOTE 1 For systems that provide access for multiple users, such as library systems, conversion back to a default profile can be advisable. NOTE 2 It is often useful to be able to access the preference settings over a network. Doing this in a secure way would preserve privacy especially for people who are worried about revealing the fact that they have a disability. NOTE 3 It is preferable to minimize the need to restart the system or application in order for changes in user interface settings to become effective. EXAMPLE 1 Platform software allows each user to save global settings for font size, sound volume, and pointer-control settings that apply everywhere on the system. EXAMPLE 2 A software application allows users to configure and save settings for font size and style within a particular window. EXAMPLE 3 The profile for a public library system is modified for the needs of a current user but returns to default values when that user is finished. EXAMPLE 4 For a person completing an on-line process who has to make adjustments to the accessibility feature to reduce errors, restarting the operating system or the user agent would cause loss of work. * * *8.2.6 Provide capability to use preference settings across locations [ANSI Level 3]* Software should permit users to transfer their preference settings easily onto a compatible system. NOTE 1 Portability is important for users with disabilities because they could find a system difficult or impossible to use without preferences set to meet their interaction needs. The overhead and effort required to create preference settings can be a significant hindrance to system usability if it must be repeated at every location. NOTE 2 User preferences profiles are sometimes made publicly available, e.g. for download from the Internet. Because people can be concerned about others knowing of their disability, it would be helpful if their use of these resources could be kept private. NOTE 3 Some platform software can provide a general mechanism for transferring their preference settings; in such cases, software might not have to implement this feature itself, as long as it follows platform conventions for storing its user preference settings. EXAMPLE 1 A user visiting a different building on the company network logs in and the system automatically locates and uses his or her personal preference settings from the network without having to edit configuration files. EXAMPLE 2 A user loads a preference settings file from a USB (universal serial bus) drive onto a new computer. EXAMPLE 3 A user's preference settings are loaded from a smart card onto a new system. Thanks, Greg
Received on Thursday, 11 June 2009 06:47:15 UTC