Re: Some thoughts on designing software accessibility standards

Some quick comments.

1) priority Levels.

-  the obvious difference is that some are higher than others.   What  
is usually desired however is the exact reason something is on one  
priority rather than another and when the different levels should be  
used/ required etc.

      We found that it is often a very complex set of interacting  
factors that determine a final level.   It is good to describe these  
as best you can.  But it is often not possible to create a specific  
formula.   It should be described as well as possible though.

     With regard to use....   in WCAG we see it as a ruler.  The  
objective of the WCAG WG was to create the ruler.    It may then be  
used in different ways to measure things in different  
environments.      How good is a padlock?   Depends on what you are  
locking up.  For a shed with garden tools it might be great but  
totally inappropriate for a nuclear storage facility.


2) General vs Specific

additional comments
- interoperability standards can't be made general.  That is one place  
where things MUST be specific or there will be no interoperation.   If  
you look at connector or connection standards you will find them very  
specific.

- RE standards
-- if they are voluntary then they can be general or specific - and  
should be whichever is most appropriate based on current knowledge.   
  -- if they are mandatory (or could be) then you have the dilemma  
of   RESTRICTIVE (specific)  VS   IMPOSSIBLE TO KNOW WHEN YOU HAVE  
COMPLIED (general).   This is an age old problem and general is not  
always the answer and can make it very hard for companies to know what  
to do and "pass".


Got to run but thought I would toss these in here.

Look at Understanding WCAG doc for things considered in WCAG re levels.





Gregg
-----------------------
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison










On Jun 25, 2009, at 3:55 AM, Greg Lowney wrote:

> Designing Software Accessibility Standards
>
> Greg Lowney, 2009-06-24
>
> It's not always easy or clear how to assign a priority level to a  
> proposed success criterion. Here are some thoughts that might be  
> useful in the process, and I'd greatly appreciate any feedback or  
> discussion. (A rich-text version that includes tables is attached;  
> the plain text was exported using a macro, so please let me know of  
> any formatting errors it might have introduced.)
>
>
> Table of Contents
>
> 1. Priority Levels    1
> 2. General vs. Specific Language    1
> 3. Questions for Prioritizing    2
> 4. Assigning Priorities    3
> 5. Splitting and Combining Provisions    3
> 6. Scope and Exemptions    4
>
>
> Section 1: Priority Levels
>
> The current drafts of UAAG20 use three priority levels, but do not  
> define the difference between them. In this discussion I use a  
> system derived from ISO 9241-171 and ANSI 200.2, dividing success  
> criteria into three categories:
>
> 1. Requirements represent the minimum accessibility requirements  
> that are expected of all software. They represent the set that would  
> be required and hopefully verified when compliance has significant  
> impact (e.g. government purchasing requirements), and so should be  
> objectively measurable and represent a reasonable expectation. It  
> means, "If you don't do this, you're not even meeting minimum  
> expectations." Requirements are denoted in ISO as "shall"  
> statements, and in ANSI 200.2 as "Level 1".
>
> 2. Recommendations are optional, and do not need to be worded as a  
> strict contract because organizations are not under as intense  
> economic pressure to claim conformance. It means, "We really think  
> you should do this, where feasible." Recommendations are denoted in  
> ISO as "should" statements, and in ANSI 200.2 as "Level 2".
>
> 3. Suggestions are a subset of recommendations identified by as  
> lower priority, to help readers prioritize the large number of  
> recommendations and to flag provisions that are very difficult or  
> inappropriate to implement in some circumstances. It means, "If you  
> can do this, it would be appreciated and going beyond expectations."  
> Suggestions are denoted in ISO as "should" statements, and in ANSI  
> 200.2 as "Level 3".
>
>
> Section 2: General vs. Specific Language
>
> When developing a success criterion for a standard you have two  
> routes: be general, or be very specific.
>
> Being general is good in that it allows developers flexibility to  
> implement solutions that make sense in their contexts and to take  
> advantage of new ideas and techniques, and makes for rules that-- 
> unlike a contract--are easily read and understood.
>
> Unfortunately, being general also makes it hard to be objectively  
> verifiable, as evaluators often need leeway to determine how to  
> measure compliance.
>
> Being specific with detailed, prescriptive language is appropriate  
> when you really, truly need to make sure developers are doing the  
> right thing, such as when the standard will have teeth and so  
> parties may have incentive to abuse the spirit of the law in order  
> to claim one product complies or another does not.
>
> Unfortunately, being specific is also dangerous, because it's very  
> hard to do it right. It's surprisingly easy to inadvertently force  
> developers to do something actually detrimental in order to comply  
> with badly worded requirements, or lock them into a specific  
> implementation even after a better option has become available. You  
> may also leave loopholes which, by allowing developers to avoid  
> complying with the spirit of the law, undercut the entire reason for  
> having such a guideline. You may also force the developer to add  
> behaviors which are actually detrimental to other users.
>
> And, it's often very difficult to write specific, detailed  
> guidelines without making them complex and difficult for the reader-- 
> like contracts, which is essentially what they are.
>
> One approach to deciding between them is the following guideline:
>
> Be specific and detailed to leave no room for error when it's  
> really, truly important that developers do it right, and/or it will  
> be enforced in the near future.
>
> Otherwise, avoid hassle for yourself and your readers by being  
> general, and leaving implementation details to supplemental (non- 
> normative) materials.
>
>
> Section 3: Questions for Prioritizing
>
> Six key questions for assigning priority:
>
> 1. How important is it for accessibility? Which users will benefit,  
> and to what extent? How much more important is it for the disability  
> community than for other users? Will lack of this feature make a  
> product inaccessible or nearly so, and to what population? Does it  
> change something to possible from impossible, or merely make  
> something more convenient? If it concerns assistive technology, is  
> it making a fundamental change or merely working around limitations  
> in some or all current assistive technology products, and could the  
> solution to be AT be modified instead of mainstream software? Are  
> there other solutions, or could there be? Are other solutions  
> better? If additional tools are required, are they expensive or  
> difficult to find out about, obtain, learn, or use? (It may sound  
> callous to say that a feature which is critical for anyone is less  
> important than one that is critical for a large population, but keep  
> in mind that no product can be made accessible to everyone,  
> resources are limited, and that in some cases it is not to the  
> users' advantage to have every feature built into every piece of  
> software.)
>
> 2. Will compliance hurt or inconvenience any population? Does it  
> conflict with the needs or preferences of some users? Can or should  
> it be "always on", or the default setting, or a non-default user  
> option? Could it prevent or discourage developers from offering  
> better solutions? If the feature is significantly detrimental to  
> some users, ensure it is worded so they can avoid it, or make it a  
> recommendation rather than a requirement.
>
> 3. Is it always possible? Are there circumstances that would make it  
> impossible for a product to comply? Is it possible for all platforms  
> and technologies? Does the wording need to include explicit  
> exemptions? If it is not always possible, be sure to include  
> appropriate exemption in the wording, or else make it a  
> recommendation rather than a requirement.
>
> 4. Can it be objectively measurable? Will it be a problem if the  
> developer, evaluators, and/or users disagree as to its compliance?  
> Is testing possible? Is it realistic? Could testing be automated? If  
> it cannot be objectively measured at reasonable expense, it should  
> be a recommendation rather than a requirement.
>
> 5. How difficult is it to implement? What would be the impact on  
> developers and their products? If it is so difficult or costly that  
> it would have a severe detrimental effect on the company or other  
> users, consider making it a recommendation rather than a requirement.
>
> 6. When is compliance likely? Is compliance already so widespread as  
> to be expected? Which products already comply, which are planning to  
> do so, and which are unable able to comply by the time the  
> requirement goes into effect? Should the requirement go into effect  
> immediately, or scheduled to give developers more time to comply? If  
> a requirement would cause all or almost all products to fail basic- 
> level compliance, you must seriously consider whether this helps or  
> hurts your ultimate goal. If we cannot expect at least two products  
> to comply in a reasonable time frame, make it a recommendation or  
> future requirement. If it is already widespread enough to be  
> expected, and the other criteria are met, consider making it a  
> requirement even if is not of high importance.
>
>
> Section 4: Assigning Priorities
>
> After evaluating those questions, you may use the results as follows:
>
> 1. It SHOULD BE A REQUIREMENT (Level A) if it is VERY important, can  
> be worded so as to not be detrimental to other users, can be worded  
> to only be required in situations where it's possible, is not  
> horrendously expensive, can be objectively measurable, and can be  
> expected to be implemented by at least two developers by the time  
> the requirement comes into force.
>
> 2. It SHOULD BE A FUTURE REQUIREMENT (Level AA but marked as  
> scheduled for promotion to Level A) if it is VERY important, can be  
> worded so as to not be detrimental to other users, can be worded to  
> only be required in situations where it's possible, is not  
> horrendously expensive, can be objectively measurable, and is not  
> expected to be implemented by at least two developers by the time  
> the requirement is enforced.
>
> 3. It MAY BE A REQUIREMENT (Level A) if it IS NOT very important,  
> but it is so widely implemented as to be expected (as well as being  
> objectively measurable, can be worded so as to not be detrimental to  
> other users, and can be worded to only be required in situations  
> where it's possible).
>
> 4. It SHOULD BE A RECOMMENDATION (Level AA) if it is at least  
> moderately important, not detrimental to other users, and not  
> extraordinarily difficult.
>
> 5. IT MAY BE A SUGGESTION (Level AAA) if it is at least of some  
> importance.
>
>
> Section 5: Splitting and Combining Provisions
>
> Sometimes it's useful to split one provision into two or more. This  
> is most useful when:
>
> 1. Different aspects of the provision deserve different priority  
> levels.
>
> 2. Where it's likely that products will comply in some areas and not  
> others, and such information is thought to be useful for developers,  
> reviewers, or users.
>
> For example, allowing the user to customize the keyboard command for  
> an action may be very important if the shortcut command is the only  
> way to access the feature, but less critical if it is merely a  
> shortcut to a menu item.
>
> For example, if a user agent allows customizing keyboard shortcuts  
> in its user interface but not those in rendered content, the  
> developer may appreciate recognition of where it does apply rather  
> than simply being listed as failing a combined provision. Users  
> could use that information when choosing between products.
>
> On the other hand, it's sometimes useful to combine multiple  
> provisions into one, if only to reduce length and complexity of the  
> guidelines.
>
> For example, one recommendation that toolbar settings be persistent  
> and one that keyboard settings be persistent could be combined into  
> a single recommendation that user preference settings in general be  
> persistent.
>
>
> Section 6: Scope and Exemptions
>
> When writing very specific requirements, it's important to make sure  
> the wording doesn't cause products to fail compliance or add useless  
> features to meet requirements that shouldn't apply to them or of no  
> value to the users. This happens if the requirement's scope is too  
> broad and it fails to include appropriate exemptions.
>
> Here are some examples of such unintended consequences:
>
> 1. A requirement says that a certain option should be triggered by  
> pressing the F1 key, so an application fails because it runs on  
> handheld device that has no F1 key.
>
> 2. A requirement says that the viewport with the current focus must  
> be highlighted using a mechanism that isn't just text colors, so an  
> application wastes screen space with a highlighted border or icon  
> even though it always displays a single viewport.
>
> 3. A requirement says that viewports display scrollbars, so an  
> application provides scrollbars even if the standard for its  
> platform is the different mechanism of moving a zoom rectangle on an  
> overview map[Footnote 1].
>
> 4. A requirement says that viewports display scrollbars when the  
> content extends beyond the viewport boundary, so a virtual globe  
> application fails because scrollbars don't make sense when there is  
> no limit to how far the user can scroll.
>
> 5. A requirement says that the user be able to change the font  
> family, so an application fails because it is run on a device that  
> only uses a single font.
>
> 6. A requirement says that the user be able to change font  
> characteristics of all text, so an operating system fails because  
> the user cannot change the font used in character mode screens  
> displayed on fatal errors.
>
> 7. A requirement says that software support a programmatic interface  
> for assistive technology, so every application written for closed  
> systems fails even if they provide built-in magnification and text- 
> to-speech, and every other conceivable accessibility feature.
>
> There are four approaches to avoiding these types of problems:
>
> 1. Appropriately structure requirements so the only apply in certain  
> contexts (scope). For example, ISO 9241-171 provision 8.1.5 starts  
> "If a user interface element has a visual representation...", and  
> provision 8.2.1 starts "When the software enables the user to set  
> personal preferences, these settings should...".
>
> 2. Include specific exemptions into specific requirements. For  
> example, "Instructions and 'Help' for software should be written so  
> that they refer to the user's actions and resulting output without  
> reference to a specific device. References to devices, e.g. the  
> mouse or the keyboard, should only be made when they are integral  
> to, and necessary for, understanding of the advice being given."
>
> 3. Provide category exemptions for specific classes of  
> circumstances. For example, the Conformance section of ANSI 200.2  
> provides that software used on, or intended to be used on closed  
> systems should be exempt from clauses regarding compatibility with  
> assistive technology.
>
> 4. Provide a general-purpose exemption, such as allowing "Not  
> Applicable" as a valid response to any requirement. For example, the  
> Conformance section of ISO 9241-171 states that any requirements  
> that have been determined not to be applicable shall also be listed,  
> together with a statement of the reasons why they are not applicable.
>
>
> [Footnote 1] 1 Scrollbar - Wikipedia, the free encyclopedia -  
> Simultanous 2D-scrolling - http://en.wikipedia.org/wiki/Scrollbar#Simultaneous_2D-scrolling
>
> <Designing Software Accessibility Standards.doc>