Some thoughts on designing software accessibility standards

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