Universal Design as a process, instrument and measure in the development of new software

In the project "Universally designed CRM" run by the Norwegian Federation for the Disabled (NHF) the goal was to develop a customer management system that can be used by everyone. Microsoft Dynamics CRM was used as a framework, and precisely this is the important goal in the project: to check if such a framework includes the necessary functionality to implement a universally designed system.

I was commissioned to test accessibility and to act as an expert on computer technology tools and Web interfaces. In this paper I summarize some of the lessons learned from the project on how to set up key focus areas for universal design in the development of new software. Since NHF wish to provide general advice with respect to Universal Design (UD) and development projects, I have also included experience from other work and references for those who want to learn more. The references are generally available free of charge on the internet.

In this paper, I have not focused on the benefits of universal design. If you are reading this you probably know that taking account of different assumptions and needs is important, and you may know that this will improve profitability. You probably know that taking account of disabled people often leads to better systems for everyone. These are quite common assertions [5], and perhaps they are even right!

The guide is written with the hope that the language is not too academic and that it is easily understood. Among other things, the I-form is used. This does not, however, in any way mean that the experience and knowledge generated in the NHF project is mine alone! Columbus IT and Microsoft has done a good job. Nevertheless, it is primarily the Norwegian Federation for the Disabled that should take the credit for being so seriously involved in such a complex project!

Thank you for letting me be part of this, and for all the experience I have gained in this project! A big thank you also to the Research Council of Norway and IT Funk who supported the project!

Please contact me if you have questions or other feedback.

Morten Tollefsen
January, 2011

1. Introduction

The Norwegian Federation for the Disabled (NHF) is an organization with about 20,000 members, about 2000 representatives and 80 employees. The organization consists of 9 county committees and 200 local branches with 12 national federations with about 100 local committees.

NHF decided to acquire a CRM system [11] for managing customer relationships. CRM will contribute to a comprehensive, systematic and structured approach to managing the organization's relationships. A relationship is defined as a person or company or institution who, for various reasons, have or have had contact with NHF. The tool will be universally designed so that it can be used by anyone regardless of any disability. "Anyone" in this context means "anyone who naturally falls into the target group for the CRM-tool" [10]. The organizational goal for the introduction of such a tool was to increase NHF's influence, and to increase their income.

After the decision was passed to acquire new software, several CRM systems and suppliers were investigated. The conclusion was that no ICT-based CRM tools were universally designed. NHF has employees with various disabilities. These employees had previously experienced problems with other ICT tools, and the new solution should be usable for everyone. This is a mandatory requirement for NHF, and will eventually also be mandatory as a result of the Anti-Discrimination Act [12]. The law was initiated by NHF, and it is important that the organization should stand in the forefront also with respect to the design of technology.

The choice of product or framework is important for the ability to develop solutions that can be used by everyone. In many cases the choice of supplier will be important. There are currently few software vendors who have expertise with respect to various disabilities. NHF quickly realized this and took the initiative to conduct a research project related to the new CRM system. Several challenges were very clear right from the start, for example:

Universal Design (UD) involves more than accessibility
Computer technical aids present content in different ways
There may be limitations in the framework and / or development tools that prevent freedom of choice with respect to implementation.
User testing is complicated, because it is difficult to define user competence
...

The goal of the research project was defined as follows: "Investigate and document what is needed to make a standard CRM framework accessible and implement this solution in NHF. " Whether the main objective has been achieved is not questioned here. The purpose of this paper is to convey the experiences of NHF in the planning, implementation and early operation of the new system. These experiences are not specific to CRM, but should be used in all similar ICT procurements. The following milestones / project activities were set up:

Define functionality based on the specification
Identify challenges relating to accessibility
Test standard solutions with respect to Universal Design
User centered design in the implementation of the NHF solution
Adjustment
Document experience

1.1 About this paper

Chapter 2 defines universal design as this term is used in the NHF project. The chapter can also be used as a first introduction for those unfamiliar with the term from before.

Chapter 3 deals with the early phase of the development project. It focuses on issues related to UD. Development methodology etc. is not discussed in detail.

Implementation and user testing are covered in Chapter 4.

Training and documentation are part of the success criteria for a successful ICT-system. This is described in Chapter 5.

The operating phase of an ICT system involves support, debugging, development, training of new employees, etc. Some of these issues are addressed in Chapter 6. The NHF project will end, however, before there is a lot of experience with operation, and this chapter is essentially a summary of experience from other work.

The paper is summarized with a check list in Chapter 7, references in Chapter 8, and appendices.

2. Universal Design Without Exception

The title of this paper is "Universal Design as a process, instrument and goal in the development of new software." In simple terms this is exactly what it is about. UD should be a part of our thinking and part of the toolbox, not a separate and limited focus.

2.1 What is Universal Design?

I am not sure when I first heard "barrier-free/accessible/universal design", but it was probably in the early 1990's. The words describe something along the lines of "the most for as many as possible". This I understand, but otherwise the term is relatively vague. Is it possible for example to say that a single website or a single PC application is universally designed? Obviously the answer is no! Yet the concept is important, perhaps most important for describing processes, rather than finished products and services. What is an important goal is universal development, which means that all development should take into account that people have different assumptions and needs.

The traditional definition of UD is "Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design." (The Center for Universal Design, Ron Mace http://www.design.ncsu.edu/cud/about_ud/about_ud.htm)

The work done at The Center for Universal Design at North Carolina State University [13] considered the starting point for the concept of "universal design". A multidisciplinary group has set up seven main principles (cf. [14] for definitions and guidelines):

Equitable use
Flexibility in use
Simple and Intuitive
Perceptible information
Tolerance for error
Low physical effort
Size and space for approach and use

Product development is based on the target group. It is natural for me that a definition of universal design does the same. All products should not necessarily be equally suitable for all people, but universal design will be used as a principle for achieving accessibility for the whole group.

I have therefore proposed the following interpretation of Universal Design for the development of software: Universal Design in ICT means that products and services should be developed in such a way that all who naturally fall into the target group are able to use the technology in an appropriate manner. [10].

2.2 Physical accessibility

In a development project, meetings, courses and conferences are conducted. Physical accessibility for everyone is necessary so that they can participate in an appropriate manner. Facilities must be suitable for wheelchairs, an induction loop should be provided, guide dogs must be allowed, consideration should be taken to allergy sufferers etc. The Delta Center has published a guide for meetings and conferences which includes a checklist that is useful for planning physical accessibility. The guide also includes advice on the distribution of materials and how presentations should be conducted.

2.3 Project team, competence and communication

Putting together a good project team is not trivial:

Specialist expertise, in for example project management and system development.
Anchoring in customer management.
End Users
Programmers, designers and other "developers".

This is obviously not a textbook on how to assemble the project team. But UD should be included as one of the prerequisites. Knowledge of computer technical assistive devices, special accessibility features in the operating system and / or development environment, problems related to accessibility in existing IT systems and more are areas of expertise that can easily be underestimated.

For users with disabilities, experts in IT and universal design are often brought in too late in development projects. Even in deliveries where universal design is part of the specification, I have seen a number of examples where UD is completely omitted, or more or less random tests are made shortly before launch, when there is little leeway to make changes before the system is in operation! Towards the end of a development the "pot" is often empty, and usually the pressure is on just before launch.

The benefits of getting early access are:

Known errors can be avoided.
Key challenges can be identified early.
Developers can learn about how assistive technology works in practice (before creating the user interface, defining processes, etc.).

In addition to benefits with respect to usability and functionality there are economic gains[5]. UD expertise from the start is guaranteed to be cheaper than "fire fighting" afterwards. Also UD does cost, and these expenses should be included right from the start during the planning phase of the project.

2.3.1 Recruitment of experts and users

Exactly who the experts in universal design are, is a matter for debate. When the Norwegian Anti-Discrimination Act came into being, individuals and groups appeared all at once with "long experience" in this field. Of course there are talented people, both in Norway and elsewhere in the world, but it is often a problem that the client does not know what to expect and which demands should be met. One example is the use of screen readers for blind people. Can someone who only has experience with the visual user interface, be an expert on the use of Braille, synthetic speech and navigation using the keyboard, and screen reader functionality? Can they understand the navigation strategies and appropriate techniques for the blind, without ever having worked as a blind person over a longer period of time? To cater for the blind is the most complex issue relating to the development of universal solutions. The reason for this is simple enough, that the visual interface has the primary focus in most development projects. Design to take into account cognitive disabilities is also very challenging, but falls a little outside the main target group for this paper. If you have experts on accessibility / UD in the project team, you should check both their expertise and references. Having tried a screen reader for few hours hardly qualifies for an understanding of what it takes to make complex systems usable for blind and severely visually impaired users.

I believe that it is quite difficultit to recruit good UD experts in many cases . In addition, users of the system should be included in the development process. Users know the tasks to be solved, internal processes and workflow in the organization, challenges in existing solutions, etc. Experts cannot replace "real" users, and one cannot expect users to know how the various challenges are to be solved technically. In many cases, the users of a web-based interface will need a basic level of competence. This is true generally, and is essential for complex computer technical assistive devices. Which expertise is needed in a given project will vary. An attempt to define the competence necessary for visually impaired to use the web has been developed in the research project "Universal User Competence" [16].

An argument I often hear relating to selecting people with disabilities is that it is important to avoid expert users. In some cases this may certainly be right! On the other hand, skilled users of screen readers and other assistive computer technology often know the techniques that are the least mentally demanding and most effective, and which solutions work best with the tools. It will help less competent users that experts find good solutions and that these solutions be taught. Who would you prefer as a driving instructor? An experienced driving instructor or someone aged 8 who is good at "Need for speed"? A rather rhetorical question, but not unlike the problems I am often confronted with in development! I have often seen examples of poor solutions that have been created through bad advice from users. This applies primarily to web pages, but also to several independent applications (and even computer technical aids for the disabled).

2.3.2 Users must be given the necessary information and competence

If users are to have a chance of contributing in a meaningful way, they must receive adequate training! This includes:

Training in what the new system will be used for and the assumptions / limitations for implementation.
Accessible and user-friendly information.
Accessible meetings ....

The last point is the one people most often neglect. My experience as a participant in development projects, including the NHF CRM project, is that not enough consideration is taken to the visually impaired. Some examples:

Screenshots shown at meetings which are neither explained nor can be made accessible on the user's PC
Presentation Software used to display the system overview, processes, etc.
Documentation is delivered in formats that cannot be read by everyone (e.g scanned PDF).
Training and documentation that necessitates the use of the mouse (although there are alternative ways)
...

If the process is not universally designed, then the final product is hardly likely to be optimal either. If the process is not adapted for everyone, then some participants will miss out on the opportunity to contribute: the user becomes a hostage. There may be one or several people with a disability participating on paper, but what good is it if they are not able to contribute to a better product? Those who make the system will get their money, but it is hardly an optimal system for the customer.

In fact, this already starts in some cases with the "introductory sale". Sellers of various products come with PowerPoint presentations, and possibly some paper brochures. If you want universally designed products, you should expect UD presentations too! In recent years I have seen several examples of suppliers who take a chance on saying that they can deliver universally-designed systems. When it comes to it, however, it appears that they have no idea what this means. They do not know about frameworks (eg Microsoft Dynamic CRM) or how these can be adapted to users with alternative user interfaces.

2.3.3 Training the developers

When designers and developers are able to watch people with disabilities use products like theirs, most of them become highly motivated by a new understanding of accessibility. Rather than seeing accessibility only as a checklist item, the real-life experience shows the human side of accessibility. Designers and developers get a different level of understanding of the opportunity for their work to impact lives. [5]

The fact that developers understand how computer technology assistive devices work is essential for making good progress and success in development projects. In addition, developers are often motivated by seeing how disabled people use the technology [5].

Modern user interfaces are usually very visual. This is especially true for computers. Assistive devices that enable the visually impaired to use standard operating systems are not like the visual interface. In the web interface for example developers must understand the way in which a screen reader presents the page in order to produce good solutions. The non-visual transformation occurs because a blind person only reads a few Braille characters at a time and / or hears one word at a time read aloud by synthetic speech. Here it is important to point out that use of the keyboard in many cases requires special measures in relation to the development of user interfaces. A special variant of keyboard use is switch systems. If functionality is to be controlled effectively with switches then for example "local jumps" must be added to avoid too many switch presses or long waiting time. Of course there are also other aids that work best if they are taken into account early in the development process.

The method used to train the developers can range from sitting with disabled users for a few hours, to taking a certifying course [8]. The course, "Universal design and assistive technology" [8] is the result of a project supported by IT Funk, and participants have stated that the training the course offers is very valuable. This is most likely because there is a lot of emphasis on practical demonstrations in the use of assistive devices.

3. Specification

3.1 Concept development

The need for new software may occur for various reasons:

Old software malfunctions or there is a need for more effective solutions.
New tasks need to be solved.
Legislation changes requiring new systems.
Integration with other systems does not work or it may be desirable to develop this type of functionality.
...

People have different assumptions and needs. In a concept development phase it is therefore natural to involve all users concerned. In my view there are two main reasons to put special emphasis on the ideas / opinions from people with disabilities:

People must, in many cases, compensate for lack of functional ability by using creativity. Strategies disabled people have established may be valuable in connection with redevelopment.

The needs of disabled people are not always easy to identify for others. These requirements can be of additional value for everyone without making the project more expensive.

Strategies / creativity: Support for appropriate keyboard use as an alternative to the mouse is lacking in many user interfaces. Those primarily using the keyboard (for example the severely visually impaired, those with mouse related strains) know a lot about standard keyboard shortcuts, about solutions that work well or poorly, and they may even have ideas on innovative practices. The strategy when using a web-based interface with a keyboard can be quite different than if the mouse is the primary input device. Good keyboard solutions can, in addition to helping some users reduce the chance of mouse related strain, probably also increase effectivity compared to using the mouse alone.

Other requirements: An example showing that disabled people can have different needs than the "average user" is the scanning of incoming post. Without optical character recognition a blind person cannot read the post. Automated character recognition is easy to put in place, and in addition to enabling the blind to read documents it provides great value for everyone, as it makes documents searchable.

By incorporating the principles of universal design in the planning phase, the contractor may save considerable funds in relation to having to convert or adapt the product in retrospect so that more users can benefit from the product [17]. The use of an interdisciplinary procurement team (TAT) may be an appropriate way to define needs [17].

3.2 Standards

There are no standards that guarantee universal design. Fortunately, however, one does not need to reinvent the wheel. One should put effort into identifying existing guidelines and standards.

The accessibility guidelines for the web are the ones that are most established for accessibility. W3C has a dedicated group working on accessibility. In a complex system such as a web-based CRM system, the following sets of the W3C guidelines apply:

Authoring Tool Accessibility Guidelines (ATAG) [1]
User Agent Accessibility Guidelines (UAAG) [2]
Web Content Accessibility Guidelines (WCAG) [3]
Accessible Rich Internet Applications (WAI-ARIA) [4]

Accessibility is less extensive than UD. Universally designed products are accessible, but accessible products do not have to be simple to use, easy to understand, etc. [19] states the following about web standards for UD: "The Standards Council has proposed that WCAG 2.0 Level AA should be a mandatory standard for web sites for public companies, and that level AAA is to be recommended. Furthermore, it is proposed that ATAG 1.0 at all levels should be mandatory for a publishing tool. These proposals will be sent out for consultation before they are put into the Reference Manual and regulation for IT standards in the public sector. If you are in the process of developing a new site, it is strongly recommended that there is full support for WCAG 2.0 AAA and ATAG 1.0 AAA. If WCAG 2.0 is established as the government standard, WCAG 1.0 will change status from "recommended" to "phasing out". If the goal is UD, one must certainly not assume that standards are completely adequate, but described above, they are a useful tool. In [19] testing with people with disabilities is recommended as part of the specification for demands.

In international standardization work accessibility and universal design are increasingly a focus. The Standardization body ISO / IEC has drawn up Guide 71, which is translated into Norwegian. This guide is also adopted by the European standardization bodies CEN and CENELEC. The guide provides instructions for standardization groups on how to incorporate universal design into the work on the development of standards. In 2008 EU launched an initiative to step up standardization work groups' use of the guide and a CEN working group was set ut with this purpose. The guide identifies areas that should be taken into account in the design of products, services, construction, environment, jobs, etc., such that the standards do not restrict the design. It provides guidance on how to take into account the needs of elderly and disabled early in a design phase such that the design is universal, that is, accessible and user friendly for everyone. Some relevant standards for ICT are found in Appendix 1.

3.3 Tender / specification

[17] places special emphasis on the following points in relation to safeguarding UD in the design of a tender:

Specification
Qualification Requirements
Assignment criteria
Contract Terms

It is important to state clearly in the tender document / specification what is meant by UD. I have seen many examples of tenders / specifications which say only: "The solution should be universally designed." This is both inadequate and defensive, inadequate because it is impossible to verify whether the solution is universally designed without setting specific requirements and the end result would be much better if the requirements had been clearly communicated, defensive because it clearly shows that the employer does not know what lies behind the concept universal design.

There are resources online that can be used to get good advice on the formulation of tender documents / specifications [17, 18 and 19].

3.4 Choice of technology and supplier

Many development projects are based on competitive bidding. There may be different contractors using different or identical technology. In many cases, as in the NHF project, solutions are created using ready-made frameworks (Microsoft Dynamics CRM, Microsoft Sharepoint, EPiServer etc.). Both the technology and the expertise of the suppliers are important prerequisites for achieving the goal that the system should be usable for all end users.

Sellers and developers live in different worlds. While sellers have a tendency to trivialize what it means to give universal design emphasis, developers do not often have the necessary prerequisites to succeed. Sellers are usually happy if the word "accessibility" is mentioned about the product they are working with, but a demanding customer often has much higher ambitions relating to UD than that a computer system meets certain accessibility criteria. It is quite simpley not good enough if "the system can be used with a keyboard." means for example that something done with a single mouse click, alternatively requires 20 keystrokes (not unusual in web interfaces where pressing tab up to 200 times may be necessary to get to the correct link, or get focus on a control). See, for example [20] for how a few simple mouse clicks can be replaced by the keyboard in Microsoft Dynamic CRM.

The Anti-discrimination Act has resulted in an increased need for skills related to UD. Suddenly, many suppliers have in-depth knowledge about both accessibility and UD. Unfortunately, it often stops with the advertisement for the senior consultant. In my experience the expertise of the consultant is that he/she has heard about or maybe even read WCAG. In creative application development, it is obviously not the case that UD can be guaranteed with just a few simple guidelines. UD requires also both expertise and creativity! So ask the suppliers to document what they know about UD and how they will ensure that UD is an integral part of the project.

If the computer systems are being created from scratch, then you normally have greater flexibility, providing the potential for "optimal" solutions. The drawbacks are considerable: expense and time are probably the two most important drawbacks. Using Microsoft Dynamics CRM or other frameworks gives less flexibility, and often there are practical or technical limitations relating to what it is possible to change. Ask for documentation about accessibility and the practical and technical limitations that exist in relation to changing standard solutions.

4. Implementation

4.1 Development Methodology

In all probability, there is no development methodology that ensures UD. Traditional methods such as the "waterfall" can include detailed specifications also for UD. My experience is that in practice such detailed specifications are not feasible in complex development projects. Modern methods such as Scrum [21] are perhaps more suitable, but UD has to be an integral part of the sprints, teams and goals, in other words, an integral part of the process.

One of the activities of the Web Citizen project [22] is to investigate development methodology where UD is an integral part of the methodology. The preliminary conclusion from this project is that many methods can be used, but that there must be measures to ensure UD.

4.2 User-centered design

"User-Centered Design" is a means to achieve UD. What distinguishes user-centered design from ordinary product development processes, is that there is a particularly strong motivation to focus on and take into account users during product development. If one is to achieve user-centered design, user reviews and experiences must not only be included in the project, but must be decisive and crucial factors in the design process. This means that we must create a product development process that allows user-centered decisions as criteria for transition to the next phase. There must be a process which gives opportunity to acquire or develop knowledge about users and user situations before decisions are taken [23].

The term user is applied primarily to the end user as the person or persons associated with the product in a user situation. The end users' capabilities, needs and desires are key aspects in the design process. The users are people with different ways of working, which evolve throughout their lifetime, as their needs change. It is therefore important for those involved in the product development process, to gain knowledge about human functional abilities, development, assumptions and needs, both physically, mentally and socially. At the same time we are influenced by the products, systems and environments which already surround us. [23]

"The power of product design" [23] is a good introduction to what user-centered design is all about and user design is not described further here. Use of a computer system, also by Disabled, is absolutely essential for success. It is, however, relatively challenging to take account of every possible assumption and requirement. If the goal is that a product can be used by everyone in a defined target group, then it is not certain that the project will have users representing every need. A customer may be interested in employing a disabled person, but may not necessarily employ people with all types of disabilities. One should therefore consider including experts in UD in all development projects.

4.3 Test Environment

A practical challenge for many development projects is to set up appropriate test environments. This is especially the case when testing involves advnaced assistive devices. Users may not necessarily use their own equipment for testing, and the test environment is often both expensive and knowlege intensive to set up. There may be technical challenges associated with user testing, for example, virtualization technologies and / or thin clients [7]. Suitable test environments should be planned early in the project to avoid practical problems so that test environments are ready when needed.

4.4 User testing and expert evaluation

It is important to choose suitable users for testing (see 2.3.1) and provide these users with the necessary training (see 2.3.2). Often it may be appropriate to let UD-experts, especially those with in-depth expertise and practical experience in computer technical assistive devices, make an expert evaluation before release to users. Experts will be able to identify many typical problems and outline possible solutions. The experience can easily become negative for testers if unnecessary errors make the system difficult or impossible to use. Expert evaluations are in practice far less expensive than user testing. Make the system to be tested as good as possible, and user testing will then provide an even better result!

Various challenges with Microsoft Dynamic CRM 4.0 were identified during expert testing in the NHF project (cf. Appendix 2). This testing related specifically to the screen reader Jaws version 10 (i.e.testing was specific rather than broad ranging to uncover all potential challenges). Without taking certain measures, little or nothing would have been gained by allowing an "ordinary" Jaws user to start testing. The challenges found were discussed with Microsoft. Some were well known issues, others were new for Microsoft. In CRM 2011 several problems are resolved and the project felt that there was a great deal of goodwill with respect to taking accessibility issues seriously. Another advantage of expert testing with Jaws was that users could be presented with workarounds to minimize problems during testing. The goal should be that Disabled have the opportunity to test the functionality of the system, that it is working as intended, that appropriate data are recorded, that the Metadata are suitably defined etc. The goal is not that Disabled should only test accessibility!

5.0 Training and Documentation

5.1 Courses

Training should, as far as possible, take into account different assumptions and needs. This can for example mean that the course participants are able to use either the mouse or the keyboard. This sounds simple perhaps? In practice, however, it is not common that courses holders use the keyboard to perform every tasks. There are several reasons for this:

The mouse pointer is visible on the screen, and it is easy to demonstrate movement of the pointer to change focus. Keystrokes are not visible in the same way.
Normally, most participants are more used to the mouse than the keyboard (except for text entry). This also generally applies to the instructor.
It is time consuming to show everything with the keyboard.
It is time consuming to show alternative techniques.
It is confusing for participants that all functionality is demonstrated in alternative ways.

Is the system adequately developed, if it is too cumbersome to display keyboard techniques? Participants can easily be confused by too many "paths to the goal." This is clear when screen readers and other assistive computer technology must also be used. It is probably not usual that trainers have the necessary skills to teach users with special needs. On the other hand, experts in these aids may not necessarily be experts in the system that has been developed. If training is to be successful for everyone, then good planning is required.

5.2 Interactive tutorials and online help

Virtually all learning materials are now available "online". Electronic information is well suited to allow for alternative presentations (information can for example be displayed on the screen, read aloud with synthetic speech, printed in Braille, etc.). It is really not so difficult to ensure that the information can be used by everyone. WCAG provide for the most part sufficient guidelines, but some expert testing might be considered (e.g. relating to search and navigation). Two of the main challenges related to good documentation are:

1. Writing comprehensibly
2. Allowing for alternate user interfaces.

5.2.1 Writing comprehensibly

Writing comprehensibly is not trivial. All too often documentation is made by technicians who write terms end users are not familiar with. To hit on the right level of explanation is difficult. If explanations are too brief, they will not help ths users. But if statements are too long and elaborate, noone will bother to read the documentation. The documentation should be tested by users, especially by people who have not participated in the process.

5.2.2 Consider alternative user interfaces

Web-based user interfaces together with screen readers represent a special challenge in terms of documentation. The information is reformatted and presented in a column for synthetic speech and Braille. Explanations such as "Click on the button in the upper left," "... is displayed with a red icon", "point with the mouse to show an explanation", etc. are totally meaningless for a blind person.

Special accessibility features should be explained. Examples are:

Text and controls that do not appear on the screen, but that are added to make it easier for screen readers.
Flash that can show alternative controls and information to screen readers.
Keyboard shortcuts

5.3 Super users and exchange of experience

It is common that some users are given additional responsibility for the system. These users will be a resource for others and may also have special rights. Many disabled people (particularly severelyvisually impaired) must unfortunately serve as their "own IT manager and super user". This is understandable in so far as they use special tools, but it is obviously not desirable! At least one super user should be given training and have a special responsibility in relation to those who use special tools. The super user cannot be expected to have in-depth knowledge about the aids, but he / she will understand the main features and how the tools are used.

5.4 Other training material

In addition to online documentation, other training materials can be developed, for example:

Introductory articles on the web or in the weekly newspaper.
Getting Started booklet.
Paper-based or electronic reference cards.
...

The same guidelines as mentioned in Section 5.2. apply to these types of educational materials.

5.5 Technical Documentation

Experience has shown that special accessibility features are not documented well enough. This is unfortunate for many reasons:

Functionality can be lost or destroyed in connection with upgrades or the introduction of new functionality.
Super users and IT personnel who were not involved in the development will not know about accessibility features in the system.
Knowledge of the solutions developed is not kept for further development or new projects.
...

Provide technical documentation for accessibility features. This must be written so that developers who were not involved in the project will have useful documentation.

6. Operation

Computer systems are developed to be put into operation. The operating phase has not been part of the NHF project, but some general tips are included below. UD also has to be put into operation:

Training of new employees (see 5.1, 5.2 and 5.4)
Help (see Chapters 1 to 5)
Further development (see 5.5)

6.1 Setup of special client equipment

The setups for Client equipment for disabled people often differ from the organization's standard:

computer technical aids (speech recognition, screen reader / magnifier, eye control, switch solutions, ...).
Special setup for software (high contrast, minimization of visible objects in the user interface, ...)
Increased privileges (e.g. to be allowed to surf, to get assistive devices to function
...

Establish good routines so that these client machines do not lose their user-specific septup, and that this special equipment is remembered during upgrading.

7. Checklist for Universal Design in development projects

7.1 Universal Design

Universal Design must be integrated as a process and a policy. This implies focus on physical access to meeting places (indoor and outdoor), documents, communications, etc. To demand or test that a final product is universally designed is difficult.
Development should take into account that people have different assumptions and needs. This should be applied throughout all phases of the project from concept to operation.

7.2 Project team, competence and communication

Expertise in UD should be a prerequisite when a prject group is put together.
Experts and users with disabilities must participate from the start of the project.
Check the qualifications and references for UD-experts.
Make a serious selection of user representatives and ensure that they have the necessary ICT skills.
Consider carefully whether the project is best served by expert users or if inadequate ICT skills do not matter.
Ensure that all information and communications are universally designed, i.e. throughout the whole process! This applies to all presentations, meetings, brainstorming, suggestions for functionality, what is to be stored, metadata, ...
Everyone must be given a good introduction to the main functionality of what is to be designed, for example what a CRM system is, how to integrate CRM with other systems (e.g. economy, intranet etc) and other factors that are important in order to participate / share expertise in a meaningful way in the project.
Teach the developers assistive device functionality.

7.3 Specification

Use the creativity and strategies suggested by people with disabilities during the concept development phase.
Identify the needs of the disabled at the earliest possible stage. These needs can have added value for everyone.
Identify current guidelines and standards that can be used to achieve accessibility and UD.
State clearly in the tender / specification terms. what is meant by UD.
UD should be an integral part of the tender documents / specification, i.e. UD is not taken out as a separate paragraph, or chapter etc.
Ask contractors to document what they know about UD.
Ask for documentation on accessibility and the practical and technical limitations that exist in relation to changing the standard solutions.

7.4 Implementation

Existing development methodology does not ensure UD, but different methods can probably work given that UD is an integral part of the entire development process.
Be sure to use techniques that involve users (user-centered design).
Include experts on various assumptions and needs to secure knowledge that may not necessarily be found among users directly involved in the project.
Suitable test environments should be planned early in the project to avoid practical problems when it is time for user testing.
Let UD experts test and come with advice before testing with "ordinary" end users.

7.5. Training and documentation

Ensure that training takes into account that the system can be used in alternative ways.
Users with special needs can be offered alternative training.
Write comprehensible documentation.
Documentation should be tested by users, especially users who have not participated in the process.
Create documentation that allows for alternate user interface.
At least one super user should be given training and have special responsibility for users who have special assistive devices.
Create technical documentation for all accessibility features.

7.6 Operation

UD should continue into the operational phase.
Make good routines for setup and maintenance of special client equipment.

8. References

1. Authoring Tool Accessibility Guidelines (ATAG)
http://www.w3.org/TR/ATAG/

2. User Agent Accessibility Guidelines (UAAG)
http://www.w3.org/TR/UAAG/

3. Web Content Accessibility Guidelines (WCAG)
http://www.w3.org/TR/WCAG/

4. Accessible Rich Internet Applications (WAI-ARIA)
http://www.w3.org/TR/wai-aria/

5: W3C/WAI
Involving Users in Web Projects for Better, Easier Accessibility
Tested (17.12.2010): http://www.w3.org/WAI/users/involving

6: W3C/WAI
Involving Users in Evaluating Web Accessibility
Tested t (17.12.2010): http://www.w3.org/WAI/eval/users

7: Tynne klienter og hjelpemiddelteknologi
Tested (06.01.2011): http://www.medialt.no/tynne-klienter-og-hjelpemiddelteknologi/930.aspx

8: Universell teknologi
http://www.medialt.no/redirect/629.aspx

10. Hva er universell utforming innen IKT?
http://www.medialt.no/hva-er-universell-utforming-innen-ikt/242.aspx

11: Kunderelasjonshåndtering
http://no.wikipedia.org/wiki/CRM

12: Lovdata (2009)
Lov om forbud mot diskriminering på grunn av nedsatt funksjonsevne
tested (30.11.2010): http://www.lovdata.no/all/nl-20080620-042.html

13: Center for Universal Design
Tested (16.12.2010): http://www.design.ncsu.edu/cud/

14: SHDIR
Universell utforming over alt!
Tested (16.12.2010):
http://www.helsedirektoratet.no/publikasjoner/veiledere/universell_utforming_over_alt____artikkelsamling_2942

15: SHDIR
Tilgjengelige møter, kurs og konferanser
Tested (17.12.2010): http://www.helsedirektoratet.no/vp/multimedia/archive/00001/IS-1137_1120a.pdf

16: Universal User Competence (UUC)
Tested (20.12.2010): http://www.medialt.no/universal-user-competence-uuc/733.aspx

17: Universell utforming i offentlige anskaffelser
http://www.universelleanskaffelser.no/

18: Rudolph Brynn og Haakon Aspelund (2006)
Universell utforming i offentlige anskaffelser
Tested (21.12.2010): http://ww.helsedirektoratet.no/vp/multimedia/archive/00013/Veileder_Universell__13513a.pdf

19: DIFI
Krav til utforming av nettsteder i forhold til Referansekatalogen
Tested (21.12.2010): http://standard.difi.no/artikler/2010/02/krav-til-utforming-av-nettsteder-i-forhold-til-referansekatalogen

20: Aditya Agrawal
Accessibility in CRM 2011 lists
Tested (04.01.2011): http://blogs.msdn.com/b/crm/archive/2010/12/27/accessibility-in-crm-2011-lists.aspx

21: Wikipedia
Scrum
Tested (04.01.2011): http://no.wikipedia.org/wiki/Scrum

22: Nettborger
Tested (04.01.2010): http://www.medialt.no/nettborger/951.aspx

23: Tom Vavik
Brukervennlighet i produktdesign
Tested (06.01.2011): http://itfunk.org/docs/Nyheter/Artikkel-brukervennlighet.htm

Appendix 1: Some relevant standards

Standard Norges Handlingsplan for universell utforming innen standardisering fra 2004 ga følgende oversikt:
EN 1332-1 Identification card systems – Man-Machine Interface Part 1: Design principles for the user interface
EN 1332-2 Identification card systems – Man-Machine Interface Part 2: Dimensions and location of a tactile identifier for ID-1 cards 2002
EN 1332-3 Identification card systems – Man-Machine Interface Part 3: Key pads
EN 1332-4 Identification card systems – Man-Machine Interface Part 4: Coding of user requirements for people with special needs
PREN 1332-5 Identification card systems – Man-Machine Interface – Part 5: Raised tactile symbols for differentiation of applications on ID-1 cards (under arbeid)
prEN 1332-6 Identification card systems – Man-Machine Interface – Part 6: Provisions for physical accessibility, including wheelchair user access, to card reading devices
ISO/IEC 19778-1 ITLET – Collaborative Technology – Collaborative Workplace
ISO/IEC 19779-1 ITLET - Collaborative Technology – Agent to Agent Communication
ISO/IEC 19780-1 ITLET - Collaborative Technology – Learner to Learner Interaction Scheme.
ISO/IEC 24703 Information Technology – Participant identifiers
ISO/IEC 19786 ITLET – Participant accommodation information
ISO/IEC 19787 ITLET – Participant performance information
ISO/IEC xxxx ITLET – Competency, impairments, and performance metrics NP Ballot For ITLET Description of language capabilities
ISO/IEC 19783 ITLET Management and delivery – Framework for data models and binding
ISO/IEC 19788 ITLET Metadata for Learning Resources NP Ballot For ITLET Specification and use of extensions anf profiles [technical report]
ISO/IEC 19796 ITLET Quality Management, Assurance and Metrics NP Ballot For ITLET Descriptive framework for learning, education and training
ISO/IEC xxxxx ITLET Profiles of standards and specifications
ISO/IEC xxxx-N ITLET Profiles of standards and specifications – Part N: Profile of Rights Expression Language
ISO/IEC 18035 Information technology -- Icon symbols and functions for controlling multimedia software applications
ISO/IEC 18021 Information technology -- User interfaces for mobile tools for management of database communications in a client-server model
ISO/IEC 9995-7 Information technology -- Keyboard layouts for text and office systems -- Part 7: Symbols used to represent functions
ISO/IEC 9995-4 Information technology -- Keyboard layouts for text and office systems -- Part 4: Numeric section
ISO/IEC 9995-3 Information technology -- Keyboard layouts for text and office systems -- Part 3: Complementary layouts of the alphanumeric zone of the alphanumeric section
ISO/IEC 9995-2 Information technology -- Keyboard layouts for text and office systems -- Part 2: Alphanumeric section
ISO/IEC 9995-3 Amd Information technology -- Keyboard layouts for text and office systems -- Part 3: Complementary layouts of the alphanumeric zone of the alphanumeric section – Amendment 1
ISO/IEC 9995-2 Information technology - Keyboard layouts for text and office systems - Part 2: Alphanumeric section AMENDMENT 1
ISO/IEC 11581-1 Information technology - User system interfaces and symbols - Icon symbols and functions - Part 1: Icons - General
ISO/IEC 11581-2 Information technology - User system interfaces and symbols - Icon symbols and functions – Part 2: Object icons
ISO/IEC 11581-3 Information technology - User system interfaces and symbols - Icon symbols and functions – Part 3: Pointer icons
ISO/IEC 11581-6 Information technology - User system interfaces and symbols - Icon symbols and functions – Part 6: Action icons
ISO/IEC 14755 Information technology – Pen based interfaces – Common gesture for text editing with Pen-based systems
ISO/IEC 14754 Information technology – Pen based interfaces – Common gesture for text editing with Pen-based systems
ISO/IEC 15412 Information technology – Portable computer keyboard layouts
ISO/IEC 15411 Information technology – Segmented keyboard layouts
TR 19765 Survey of existing icons and symbols for elderly and disabled persons
TR 19766 Design requirements concerning icons and symbols in IT for elderly and disabled persons
TR 19764 Guidelines, methodology and reference criteria for cultural and linguistic adaptability in information technology products
CWA 14661 Guidelines to Standardisers of ICT products and service in the CEN ICT domain
CWA 14835:2003 Guidelines for making information accessible through sign language on the web
CWA Availability of alternative language versions of a learning resource in IEEE LOM
CWA 14094 European Culturally Specific ICT Requirements
CWA 14051-1 Information Technology – European generic locales Part 1: General specifications
CWA 14051-2 Information Technology – European generic locales Part 2: Narrative cultural specifications, POSIX locales and repertoiremap
CWA 13873 Information Technology – Multilingual European Subsets in ISO/IEC 10646-1
CWA 14838 – Fastest (Multipart)
CWA 14838-3:2003 Facilitating Smart Card Technology for Electronic Ticketing and Seamless Travel – Part 3: Catalogue of Technical and Business Process Requirements
CWA 14838-2:2003 Facilitating Smart Card Technology for Electronic Ticketing and Seamless Travel – Part 2: Development of Smart Card Based Interoperable Ticketing Systems
CWA 14838-1:2003 Facilitating Smart Card Technology for Electronic Ticketing and Seamless Travel – Part 1: EU Policy and User Requirements
CWA 13987-1:2003 Smart Card Systems: Interoperable Citizen Services: Extended User Related Information – Part 1: Definition of User Related Information and Implementation
CWA 13987-2:2003 Smart Card Systems: Interoperable Citizen Services: Extended User Related Information – Part 2: Implementation Guidelines
CWA 13987-3:2003 Smart Card Systems: Interoperable Citizen Services: Extended User Related Information – Part 3: Guidelines to Creating, Operating and Maintaining an Interoperable Card Community

Appendix 2: MS DYNAMICS CRM / Jaws 10

Main Issue Areas:

Searching records in the system
Lookup fields
Sometimes function work properly, sometimes not

Prerequisites for using the system:

Jaws version 10

Jaws virtual mode is used as default.

Jaws virtual mode is usually most appropriate.

Scenarios:

New case to existing relation
New case to new relation

Scenario 1: New case to existing relation

The relation calls inn and the user opens the outlook interface
Selects the outlook CRM menu and navigates to cases and opens a new case
A title is typed in and by using the tab button navigates to the relation lookupfield
By pressing enter the search for relation pops up and the name is typed in and search is started
Challenge 1: When the search result shows the user experience is different when the result is one record or many records. When the result is one record the user does not see any table at all, however when there are more than one record the table shows, but does not show any column headers because these are stored outside the table. Some (probably the full) explanation for this is that column titles (-tags) are not used. When there is one record jaws present this by saying there are 20 columns and tre records in a table. When navigating in this is not read as a real table and jaws commands cannot be used. The user must in this case just understand that there is one hit and go directly to the OK button.
Challenge 2: When there are more than one record, the first record is presented as column header. The user navigates into the table until the right record. The problem now is to select this record. There are no links in the table to the specific record to be selected. This means that the user must “drag” the jaws cursor (mouse pointer) to the pc cursor (focus in the virtual mode) which means bringing the mouse to the right record jaws is reading. Then a left mouse click is needed before navigating to the OK button. By doing this the user has no real confirmation that the right record is selected.
Challenge 3: After selecting a relation coming back to the case, jaws does no longer keep focus in the field when navigating through the case window. When navigating in the window one would normally use jaws commands to move from field to field through jaws command F, but MS CRM does only accept this command in certain situations (between picklists, freetexts, numbers and bit fields). It does not work moving in and out of lookups or notes areas. In those cases the user must hit the tab button.
Challenge 4: When using tab into lookup fields jaws does not present which field it is (ex. Owner and relation lookup)
Challenge 5: Jaws has functionality to show all form fields and values in a list. This list is used to perform quick navigation to a spesific field by using the initial letter(s) in the field name. This functionality is very important: both to check values and for the screen reader to quickly focus on a spesific field. Values and names of lookup fields and notes are not shown in the list (See screenshot).
Challenge 6: When using shift tab to navigate from the “Saksopprinnelse” picklist below the notes field and into the notes area, jaws will read the last note correctly, but will present the note as being a value in the “Saksopprinnelse” field.

Scenario 2: New case to new relation

Challenge 7: The user navigates to the relation table and performs a search for Aatangen, Stig. There is one record hit, but the user does not see and table. Standard Jaws does not read search results with one record as a table which is the same result as when there are no hits at all. The information on how many results the search presents is hard to navigate to.
Challenge 8: When the Aatangen, Stig relation is selected one might want to move into the relations cases or history to see what mail have been tracked to the relation. This is fine to navigate into, but when these lists are presented it is hard to get any information on the result. How many records, If the activity I an email or task, and no column headers.

General conclusions:

Jaws commands and keyboard commands must be used alternately through the system.
There is a lack of information to the user regarding where in the system he/she is placed. One solution (perhaps the best) is to use the <title>-tag for this.
When opening a new area in the system (ex. Cases, relations etc) the user does not see that one has actually entered the right register.
The names of hidden links in the system are not available.
There is a general lack of structure from a screen reader point of view.
Lookup fields and notes are time consuming and too hard mentally (remember what to search for, when search is necessary etc). This (search results) and several other things should have been structured using <h>-tags.
The lack of structure (headings) is one of the most important problems for screen reader users.
For a screen reader user without much knowledge on MS CRM it is difficult to know when windows open inside Outlook or as standalone IE windows.
Search results and navigation into tables is hard and results and method varies when one or more records is the result of a search.
The information about number of hits in search is hard to find.
The system is possible to use but demand a lot of navigation, many rutines and commands and is generally hard and confusing to use.

Del på Facebook Del på Twitter Del på e-post

Mainmenu