| IDCnet | |
IST–2001–38786 IDCnet
Skip to table of contents. Skip to text.
| Contractual Date of Delivery to the EC: | 31 May 2004 - Rev. due 31 December 2004 |
|---|---|
| Actual Date of Delivery to the EC: | 17 May 2004 - Rev. delivered 30 November 2004 |
| Editor: | Christophe Strobbe (KULRD) |
| Contributors: | Colette Nicolle (LU/RSEHF), Carlos A Velasco (FIT), Jenny Darzentas (AEGEAN), Rafael Romero (UVEG), Tony Verelst (ISdAC), Klaus Miesenberger (i3s3), Gerhard Weber, Kurt Weimann (MMC), Ger Craddock, Bryan Boyle (CRC), Helen Petrie (City University), Frederic Degouzon (Nantes), Päivi Tahkokallio (STAKES), Keith Gladstone (RNIB) |
| Workpackage: | 2 |
| Estimated person months: | - |
| Security: | Public |
| Nature: | Report |
| Version: | I |
| Total number of pages: | 47 (Microsoft Word or Adobe PDF version) |
This report presents an overview of industry needs with regard to Design for All knowledge and skills in employees and graduates. The overview is based on existing literature and a new survey of commercial organisations with experience in accessibility or Design for All. Finally, the report draws some conclusions about the optimal graduate profile for DfA.
Keywords: Design for All, industry needs, graduate profile, curriculum.
| Version: | I |
|---|---|
| Date: | 26 November 2004 |
| Circulation: | Public |
| Status: | Final |
| Version | Version date | Responsible | Description |
|---|---|---|---|
| A | 10 May 2004 | KULRD | First draft |
| B | 12 May 2004 | KULRD | Additions by KULRD and LU/RSEHF. |
| C | 13 May 2004 | KULRD | Additions and changes by KULRD and LU/RSEHF. |
| D | 13 May 2004 | FIT | Additions |
| E | 14 May 2004 | KULRD | Final additions |
| F | 5 November 2004 | KULRD | Addition of employee profile; update of survey results |
| G | 8-9 November 2004 | FIT, LU/RSEHF | Addition of Computer Science profile (FIT), Psychology/Human Factors profile (LU/RSEHF) |
| H | 24 November 2004 | KULRD | Addition of other employee profiles |
| I | 26 November 2004 | LU/RSEHF | Final edits |
| Version | Review date | Reviewed by | Conclusion |
|---|---|---|---|
| E | 24 May 2004 | Jan Steyaert, Andre Gubbels, Susan Hewer | Rework |
| I | March 2005 | D. Bouwhuis, Susan Hewer | Accept |
Conclusion: e.g. Accept, Develop, Modify, Rework, Update.
This report describes the needs of the ICT industry with regard to DfA knowledge and skills in employees and graduates. First, it describes links between research in industry needs and curriculum design. The next section presents a number of observations from previous investigations and surveys; these include: barriers to the adoption of DfA, the dichotomy between large companies and SMEs, and the importance of support from upper management. The next two sections present the findings of a new survey (described in the Annex), combined with results from previous surveys that covered similar ground. Findings about professional training are fit into the subcategories of the taxonomy of core DfA knowledge sets and skills defined in report D3.2. The final section outlines the ideal graduate profile for DfA in ICT and makes some suggestions on how the current findings can be used for defining an optimal graduate profile for DfA.
Defining the optimal graduate profile for Design for All in ICT-related jobs is a task that has to take into account several factors:
In the first phase of this project, industry needs were inferred from existing information (projects, surveys, other publications), not only on accessibility and Design for All but also related fields such as Human-Computer Interaction and ergonomics. This information was incorporated in the baseline document for the workshop in Helsinki in February 2003 and into deliverable D2.1. Chapter 3 of deliverable D2.1 also covered a number of new and future technologies that can be affected by the adoption of Design for All. The intention was to complete the information on industry needs with input from representatives of organisations who put accessibility into practice: they would comment on the baseline document and create profile descriptions to cover what they feel to be the needs of their sector of industry and what might be the needs of industry in four or five years time, when students graduate. However, while industry representatives are very willing to present what their organisation has achieved in this field, the workshops organised by IDCnet and other contacts did not yield much information on the knowledge and skills that companies expect or the training that they provide to their employees. To compensate for the low input, we also analysed descriptions of job openings for Web developers, software engineers, usability specialists, human factors engineers, user interface designers, quality assurance analysts, information architects and instructional designers. In addition, we contacted e-skills UK, the Sector Skills Council for information technology, telecommunications and contact centres.
Deliverable D3.2 [Darzentas, 2004, p. 9] lists four questions that should be considered in curriculum design: what is to be learnt, why it is to be learnt, how it is to be learnt, and when it is to be learnt. Reports on industry needs, which are the subject of this workpackage, cannot answer these questions directly, but can be useful resources for curriculum designers.
to enable the learner to possess the groundwork to update his knowledge … rather than to transfer a specific body of knowledge and techniques” [Darzentas, 2004, p. 9].
When discussing industry needs with regard to Design for All (or
accessibility), the first problem is that there is little awareness of
“needs” in countries or sectors that have no regulation regarding
accessibility or the discrimination of people with disabilities. Companies in
sectors where relevant legislation is in place are more sensitive to Design
for All and “tend to adopt it as part of their regulatory and stakeholder
strategies
” [UDRP]. Another problem was identified by the UK Lambert Review
of Business-University Collaboration: some university correspondents
commented that business was generally not good at identifying and
articulating its future skill requirements in any meaningful way, and that
frequent changes in business strategy meant that there was little consistency
to businesses’ stated skill needs [H.M. Treasury, 2003a, § 6.15].
The report on Web accessibility by the UK Disability Rights Commission (DRC) found a striking dichotomy between organisations with more than 250 employees and organisations with less than 250 employees. A bigger proportion of large organisations claimed to be aware of accessibility issues, that they had policies on accessibility, etc. However, the testing of 1,000 websites did not confirm the level of awareness that companies claimed to have in the survey [Disability Rights Commission, 2004, p. 36].
The DRC survey also asked about the barriers to achieving accessibility. Both website commissioners and web development agencies mentioned similar problems [Disability Rights Commission, 2004, p. 37]:
the perceived cost of accessibility, in terms of money, time and staff resources”
the low level of knowledge about the issues and how to address them, reinforced by a perceived lack of simple guidelines, expertise and skill”
the obstacles presented by the increased demand for graphics and other technical constraints”
the conflict between accessibility and other considerations, especially aesthetic and creative considerations”
general lack of awareness about the issues and their potential importance”
According to an older project in the UK, there was no widespread acceptance of the need for Universal Design training programmes [Keates, Lebbon & Clarkson, 2000].
In a survey of former students of universal design education conducted in 1998, the Trace Research & Development Center found that lack of know-how and lack of time were the most important factors that negatively affect universal design. The size of the organisation, the development process and the organisation structure were not perceived as having any particular impact on the adoption of universal design. More findings of this survey are discussed in section 5.6.
On the other hand, the interest of industry in interaction design and Design for All can be seen at the École de Design Nantes Atlantique in France, one of the partners of IDCnet. The École de Design is a private higher education institution managed by the Chamber of Commerce that offers courses on Product Design and Hypermedia Design. There is frequent co-operation with corporate groups, both with large companies (France Telecom R&D, Electricité de France, NEC/Packard Bell) and with SMEs. Some of these co-operations were initiated by the industry. One of the reasons for teaching Design for All and accessibility is that these subjects are not taught in other design courses in France; this is seen as a competitive advantage.
There is some evidence in the literature that the drive for Design for All
tends to be top-down. For example, it required little effort to convince top
management of Nokia to start the first accessibility initiative, even though
there were no expectations of significant return on investment. Accessibility
was simply “the right thing to do
” [Dzumba, 2001, p. 1]. A survey by
Trace Research & Development Center found that large companies that had
succeeded in implementing Universal Design shared a number of
characteristics, one of which was support from upper management [UDRP]. This
confirms that it is important to include awareness of Design for All into the
curricula of people who end up in supervisory or strategic decision making
situations.
This section classifies the needs that were identified in the literature and the IDCnet survey (see Appendix A) in the categories of the taxonomy presented in workpackage 3 of this project [see Darzentas, 2004, p. 21]. Sections 4.2 and 4.3 also suggest some examples of what to teach; section 5 of deliverable D3.2 and the appendix of deliverable D3.3 also contain examples, which are derived from existing courses and programs. For many of the subcategories in the taxonomy, (pointers to) material can be found on Appendix B of deliverable D1.4a. In the ICT category examples can also include results of research projects: many of the existing DfA courses are taught by lecturers or researchers who are also involved in projects that involve industry as well.
There were only three responses to the original survey, even though the questionnaire was sent to companies that had publicised their efforts in accessibility or Design for All in books, workshops or even meetings organised by DG Information Society of the European Commission. DG Information Society sent the questionnaire to approximately 20 industry contacts; only one of the recipients returned the questionnaire. The two other responses are the result of telephone interviews. The low response rate seems to suggest that the long-term benefit that industry would get from graduates with better Design for All knowledge and skills is not a sufficiently strong incentive to reply to the survey. Possibly, the recipients who did not return the questionnaire ignored it because of its length.
All network members have tried in the previous months to obtain more feedback by making use of their contacts and by attending international conferences such as ICCHP 2004 (Paris, 7-9 July 2004), to which several industry representatives attended. These efforts yielded only one additional response.
The low response rate, although expected, is somehow disappointing. When IDCnet started in 2002, response from industry was enthusiastic, and it was reflected in the first workshop participation, which reached an acceptable level. However, when the European Year of People with Disabilities finished in 2003, interest in collaborating with the project, even at a minimum level, like responding to a short questionnaire, became an almost impossible task.
Sections 4.2 and 4.3 and their respective subsections correspond to the branches of the taxonomy. The section on training in the survey was also based on this taxonomy, in order to find correspondences between what is or could be taught in higher education and the subjects covered by training in industry.
Training is not always a formal event: some companies did not mention any formal training, but on-the-job training, “internal sessions” or working sessions, and study. This is a way of updating knowledge and skills where subjects easily flow into each other; one respondent answered affirmatively to questions about each of the categories mentioned below.
During the European Year of People with Disabilities, Hewlett-Packard (HP) increased awareness of accessibility issues inside its own organisation. The company did this by:
HP stated that these activities “encouraged HP managers to have greater
awareness of the skills that our current and prospective employees with
disabilities add to our workforce
” [“Walking the Talk”, 2003]. However,
considering disability issues is not the same as Design for All.
Microsoft's Accessible Technology Group also designed “an education
programme to increase understanding and awareness of accessible technology
and disability rights and legislation as related to customers, employees and
partners
” [“Walking the Talk”, 2003].
In our industry survey, two companies mentioned that people with any role or position get training which raises awareness of DfA. For another company, a user-centred design consultancy, accessibility or DfA is a natural component of their work, so there was no perceived need to cover this subject in its own right.
Examples of what to teach in higher education include:
This subcategory covers ethical considerations, compliance with legislation and commercial potential.
Greg Lowney of Microsoft has pointed out that “lack of formalized knowledge of the principles and benefits of accessible software design” is one of the barriers to the adoption of Design for All [Universal Design Discussion].
Industry representatives have pointed out that ICT companies are often players on an international market, but legislation (and the standards on which laws may be based) is usually specific to one country. In the USA, where case law plays an important role, rulings in different states may even contradict each other. In this context, William Hudson even uses the phrase “US Web Accessibility Jigsaw” [Hudson, 2003].
In our industry survey, one company mentioned that people with any role or position get training that covers this subject. In another company, only part of the training of design and development teams.
A survey by Trace Research & Development Center found that it is
“critically important [to have] design teams who know what can be done and
who are aware of regulations
” [UDRP Student Survey, 1998].
Examples of what to teach in higher education include:
This subcategory covers recommendations, principles, guidelines, standards, best practices, etc.
Guidelines are sometimes hard to use. For example, according to Graziani,
Web developers find the Web Content Accessibility Guidelines “too detailed
and not accessible enough for their knowledge of the subject
” [Graziani,
2001].
The experience, as seen in some of the teaching pilots, shows that students generally find this subject the least interesting part of a Design for All course. It is hard to convince them that this is an important subject.
In our industry survey, one company mentioned that training and collateral materials include internal requirements (standard process reviews) and recommendations. Generally, standards and guidelines referenced include works from ETSI, COST 219, disability organisations and ISO.
One consultancy that is aware of accessibility issues mentioned that they are familiar with ISO 9241 (usability), ISO 13407 (user-centred design process) and ISO 20282 (ease of operation of everyday products; still in draft stage), but that they did not know any standards regarding accessibility.
One representative of a large company referred to activities in standardisation, but not whether this was a subject in training. This respondent also emphasised that his company likes practical solutions rather than the theoretical ones that could sometimes be found in the United States.
Another company mentioned that this was part of the training of design and development teams, without mentioning specific recommendations, guidelines or standards.
Examples of what to teach in higher education include the standards mentioned above and the guidelines and standards listed in section 11.1 of deliverable D2.1 and in Appendices A and B of deliverable D1.4a.
The existing literature mentions several types of interpersonal skills:
This subcategory covers knowledge on making content of documents, multimedia and Web sites accessible to all users, e.g., by making alternative forms of media available.
In our industry survey, one company mentioned that people in call centres, customer care and customer documentation employees get this training.
One respondent replied that this is not covered separately by formal training, but that it is a component of his company's user-centric activities. This respondent also said that the website of his company had been tested with screen readers, but that clients (including the public sector) did not ask for this.
Another respondent replied that this was only part of the training of design and development teams.
Examples of what to teach in higher education include guidelines for the accessibility of document formats and tools that check documents against such guidelines. The limitations of such tools are often ignored by current users, so this is also an important topic.
This subcategory covers knowledge about assistive and adaptive devices that enable alternative input and output, e.g., speech synthesisers, screen reader software, alternative keyboards, etc.
In our industry survey, one company mentioned that people with any role/position get training that covers this subject.
One respondent replied that this is not covered separately by formal training, but that it is a component of his company's user-centric activities. Another respondent replied that this was part of the training of R&D teams (not design and development teams).
Examples of what to teach in higher education include alternatives to keyboard, mouse and display, keyboard accessibility of GUI and Web applications, accessibility options for operating systems and applications (including APIs), and assistive technologies.
This subcategory encompasses new research being conducted in areas such as smart computing applications, smart homes, clothes, cars, etc.
In our industry survey, one company mentioned that this subject is not covered. One respondent replied that this is not covered separately by formal training, but that it is a component of his company's user-centric activities. Keeping abreast of new evolutions is considered necessary in order to be able to offer a level of service that justifies its (high) price.
One company mentioned that this was part of the training of R&D teams.
Examples of what to teach in higher education include gesture recognition and sensor-based interaction. This category of the taxonomy is also linked with the subcategory on “useful sources”, because graduates will need to know where to find results of new research.
This subcategory covers HCI and usability studies, user-centred design and evaluation methods.
In our industry survey, one company mentioned that people in Human factors engineering get training that covers this subject. One respondent replied that this is not covered separately by formal training, but that it is a component of his company's user-centred activities. Another respondent replied that this was part of the training of design and development teams.
Examples of what to teach in higher education include evaluation methods and metrics (such as GOMS: Goals, Operators, Methods, and Selection Rules, Card et al, 1983). This category of the taxonomy is also linked with “interpersonal skills” (section 4.2.4), because evaluations can and should involve real users.
Application domains where Design for All issues are relevant, e.g., public access to information, health monitoring, technology enhanced learning, e-government, e-commerce, etc.
In our industry survey, one company mentioned that this subject is not covered. In another company, this was only covered in the training of R&D teams.
This includes case studies, new information, privacy and other legal aspects, etc. An older survey by Trace Research and Development Center found that:
Almost all interviewees wanted closer ties to organizations performing research and development in UD or accessibility. Specific comments were directed toward making research results easier to find, improved market research, and industry participation in the research agenda so that more economically viable products would result. Human factors researchers in academia and elsewhere should note this interest. [UDRP]
In our industry survey, one company mentioned that this information can be found in a library to which all employees have access. Another company only mentioned this in relation with R&D teams.
Graduates will need to know what types of (re)sources exist: this does not only include books and journals, but also conferences, mailing lists and forums, web sites (other practitioners, interest groups, disability organisations, …), informal networks, etc.
Companies that implement Design for All or accessibility often work with an accessibility competence centre, which is preferably located close to the company headquarters, because support from top management is essential. Without this support, accessibility is the first area that suffers when there are budget cuts.
It is also common that companies confuse Design for All with employing people with disabilities, and they tend to display this by showing its employees as “poster children.”
All respondents mentioned that the drive for Design for All in their organisation is top-down.
One of the questions of the IDCnet survey concerns the relation between accessibility and usability. The questionnaire asks one's opinion about the following two statements:
Some respondents consider usability as an aspect of accessibility, for example with the following rationale:
What’s usable by one person may not be to another. It is not possible to require a “generic” accessible product so that it will be usable. Accessibility encompasses more than usability. It means access to information, fair pricing, availability, adaptability, and ingenuity, among other attributes.
Instead of expressing agreement or disagreement with the two statements in
the questionnaire, one correspondent wrote: “If usability is built into
all design, then accessibility only needs be verified.
”
Another respondent, however, finds that usability and accessibility should be clearly distinguished. Accessibility and usability deal with different questions. Moreover, accessibility is subject to legislation, whereas usability is not; there is a tendency to measure usability, but this is generally very hard for accessibility. Accessibility should not be integrated into usability, because this would make things more difficult for industry: it would become necessary to develop measurements of accessibility.
A respondent from a user-centred design consultancy found that both statements can be justified. On the one hand, accessibility is an area for attention in usability work. On the other hand, accessibility can be said to be a wider area because it considers both cognitive and physical aspects, whereas usability only considers cognitive aspects. This question should not be debated religiously; the two areas belong together. This respondent also mentioned that clients always make requests about usability and rarely about accessibility, and that he always brings in accessibility issues if the client does not mention it.
The IDCnet survey also asked respondents if DfA-related training:
One respondent indicated that DfA-related training may be delivered in any of the forms mentioned above and that training is driven by the individual as part of CPD (continuing professional development). Two respondents indicated that this type of training was delivered in-house by internal trainers. One respondent said that they regularly invited external experts to teach their own employees about a specific subject; what is remarkable about these sessions is that clients and other contacts are also invited to these talks. The same correspondent also mentioned attendance to conferences and other events, and that his company also delivered training and seminars.
One company mentioned that they “cover all aspects of accessibility
(need, demographics, processes, assessment) in new hire training and in
modules presented quarterly. Accessibility training is part of continuous
learning and is ongoing at all locations.
”
Other companies have no general DfA training, but only product-specific training.
One respondent mentioned that DfA knowledge on a graduate's CV would be an
added value, “in the same way that quality certification might be
recognised.
” However, another respondent mentioned that it is not necessary
for every developer to have this knowledge, because many companies that
practice Design for All or accessible design work with an accessibility
competence centre. The members of such a centre assist developers during the
different stages of the development of a product or service. Another
respondent said that DfA knowledge is an advantage but that it is only one of
many job requirements; DfA knowledge is not complex, but requires the right
attitude and study.
Surveys of former students of Design for All education are useful instruments for curriculum designers. One such survey was organised in 1998 by Trace Research and Development Center as part of the Universal Design Research Project [UDRP Student Survey, 1998]. The survey was sent to 93 former students of the University of Wisconsin-Madison, where Trace R&D is located; 19 surveys were completed.
The survey also asked respondents to describe their experiences; their comments are reproduced below:
One person spends 60% of her time considering designs for brochures targeting people with health problems. Key elements of UD training (in brochure development) include: listings of helpful services for differently-abled people first, colour coding categories with services for (people with disabilities), providing text in different languages. At the learning centre this person spent 40% of her time ensuring proper access to the building facilities for all people.
One spends 10% of his time on design of controls/switches/actuators, and 10% of his time on location of switches/controls/actuators.
One spends 5% of his time making web site and product brochure design more widely appealing.
One said taking into account the needs and requirements of different users when designing processes is helpful, as well as keeping in mind to design for a range of users.
One said UD is useful for guiding product development and user interface definition.
One remarked that in designing systems or defining organizational structure for the clients she has worked with, the theoretical aspect of Universal Design has always played a part. However, there has been no focus solely on Universal Design, as the systems she has worked on have always had a very specific user group.
One said that UD is used in developing the methods to perform a job, including workstation design and layout equipment selection, as well as job training.
One said that she designs products for both physician and patient use. In UI development, some thought of ergonomics must be integrated with the design plan.
One said she spends no time on UD, but views products and processes differently.
One said her research involves building decision support systems for caregivers of people with dementia. The target audience is around 70 years old with no computer experience and minimal education.
One noted that universal design is used when practical in the design of consumer products, computer hardware and software. Often times (90%) he keeps universal design in mind, but does not always focus directly on making the complete product universally designed, but rather pieces that make-up the complete system: size, shape, resolutions, input device, port location, software, keyboards, documentation, etc.
One noted that the course she took was a thorough, exhaustive way to think about design, coupled with a sensitive awareness of all the problems users can experience in accessing a design. She doesn’t really deal regularly with users who have special needs but considerations of those needs has always improved her designs.
Lastly, one noted that along with job placement services each client is thoroughly checked for workstation functionality.
Since the Trace R&D survey, the legal situation in the United States has changed; newer surveys would probably find different results. For example, universal design training may now be a bigger asset on the job market, but how big? Also, a larger percentage of respondents may be interested in further training. Moreover, the Trace R&D survey seemed to cover universal design generally; for curriculum designers in ICT, more focused surveys would be useful.
The original intention of this report was to describe an optimal graduate profile for Design for All that would be based on the needs formulated by the industry. Unfortunately, the input from industry was very limited over the course of the project, and in particular in the final questionnaire results. This was not unexpected: recommendations for DfA education and research policies and strategies in Europe (see deliverable D4.2 and section 5 of deliverable D1.4a) emphasise that awareness of industry on DfA needs to be deepened, and more and relevant tools to implement DfA by industry need to be developed (recommendation 2). In addition, industry and educational institutions should interact on a regular basis to identify and update industry needs in relation to DfA education and research, e.g., through existing European DfA networks like EDeAN, EIDD, and AAATE (recommendation 3). IDCnet would, therefore, recommend that the profiles described in this chapter need to be followed up as students enter the professions in order to define the most optimal graduate profile, and validate the recommendations presented here. It is also recommended that the EDeAN Special Interest Group on Design for All curricula, which seeks to contribute towards the development of an interdisciplinary curriculum on DfA, take up this work after the end of IDCnet.
The Lambert Review of Business-Industry Collaboration [H.M. Treasury, 2003b] contained a number of general but relevant observations, which have been taken into account in IDCnet’s recommendations on Design for All related higher education and research policies. To meet the needs of the economy, students should be equipped with the intellectual, specialist and transferable skills that they need to pursue a career in ICT. Because of the recent explosion of courses in the creative media and IT sectors, this is not always the case.
Funding bodies for universities (e.g., Higher Education Funding Council for England) need to take account of the views of groups who benefit from skilled graduates, such as employer-led bodies.
Since a large proportion of the initial skill-deficiencies reported by employers relate to skills and knowledge that are best acquired on the job, students must also be given more opportunities to gain experience of working in business.
It is also important for students, particularly science students, to develop entrepreneurial skills to allow them to exploit their innovations and develop the commercial potential of their work. To address this issue, Science Enterprise Centres have been set up in the UK, using government funding at 13 centres involving over 70 universities nationwide [H.M. Treasury, 2003b, passim].
The summary of consultation responses and emerging issues published during
Richard Lambert’s review [H.M. Treasury, 2003a] also stated that there is
“a clear difference between the skill needs of employers recruiting staff for
R&D-intensive roles, and those for other roles. Recruiters for R&D
roles mentioned the importance of excellence in the scientific disciplines,
stressing that although non-technical skills were useful, they must not be at
the expense of the core scientific skills. Many R&D employers felt that
declining standards in courses had resulted in graduates lacking deep
technical understanding. This was in contrast to the needs of employers in
most non-R&D areas, who were more interested in looking for generic
skills, which included both ‘soft’ skills such as communication and team
working, and business awareness. A few of these employers felt that
universities could do more to develop these skills further.
”
IDCnet would also recommend that the curricula of the European Universities in the field of ICT should be updated more frequently than is currently the case. This is critical for DfA, because accessibility is very strongly linked with leading-edge technologies, especially those that were discussed in chapter 3 of deliverable D2.1.
It is beyond the scope of the project to draw exhaustive curriculum recommendations and compare them to existing profiles in European universities. In the following, we will try to outline employee profiles (based on the industry summarised above and on actual job postings available on the Web), and suggest necessary additions that can complement existing exemplary curricula to provide a generation of graduates with knowledge about DfA in different fields. These results are a summary of the different experiences from the IDCnet partners when incorporating new graduates to their past and actual research projects. They need to be seen in the light of the recommendations mentioned above, which also complement the recommendations in deliverable D1.4a.
The employee profiles below are based on the findings described above and an analysis for approximately 150 descriptions of job openings for web developers, software engineers, usability specialists, human factors engineers, user interface designers, quality assurance analysts, information architects and instructional designers. The intention is not to provide an exhaustive description, but to mention at least those aspects that can be relevant to Design for All. Not all profiles contain the same level of detail. “Behavioural skills”, for example are broadly similar across the different profiles (strong oral and written communication skills, ability to work independently and in team environments, time management skills, multitasking, …) and do not need to be repeated in every profile.
Responsibilities include:
This role requires contacts with developers, team leaders and managers, and end users.
Since ICT and user interfaces are constantly evolving, so is the field of accessibility. A DfA expert will need to keep up with new regulations and standards (both official and de-facto standards, such as those coming from the World Wide Web Consortium).
User interfaces should be tested for compliance against certain standards (e.g., WCAG) or national regulation (BITV, Section 508, etc.).
Task examples:
ICT is increasingly subjected to accessibility legislation. Standardisation bodies create and/or update standards or recommendations for accessible interfaces.
Task examples:
Implementing Design for All in an organisation can be an uphill task.
Task examples:
DfA experts will have an understanding of a number of products and services, such as:
The IEEE Computer Society defines software engineering as
- The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.
- The study of approaches as in (1).
“IEEE Standard Glossary of Software Engineering Terminology,” IEEE, Piscataway, NJ std 610.12-1990, 1990. Quoted in [IEEE 2004], p. 1-1.
Software engineers design, implement, test and maintain software systems. The SWEBOK identifies ten knowledge areas in software engineering [IEEE 2004, p. 1-2]:
Typical tasks include:
Software engineers will have an understanding of products, offerings and services within their specialty. Examples of specialties include:
The World Wide Web is a very successful Internet application. Its emphasis on platform independence has made it a preferred interface for many applications that used to be based on other Internet protocols or on desktop programs. Web interfaces are now being used for mail, online shopping, online learning, database access, document management, content management, project management, etc. and are also finding their way into new areas such as e-government and e-health. The role of a web developer requires contact both with persons representing end users and with other technical roles in the organisation (database administrators, system administrators, security engineers).
In addition to the tasks usually assigned to them, web developers may also be required to:
(Note that the first requirement is much more common that the other ones.)
All skills mentioned at the beginning of this chapter are relevant. Other skills or attitudes that are frequently mentioned in job descriptions are:
In addition to the usual requirements (HTML, CSS, scripting/programming languages, relational database design, … and occasionally graphic design) the following requirements are worth mentioning:
Some positions also require the following:
Many of the methods and techniques used in Usability or Human Factors Engineering are relevant to Design for All, but the analysis of job openings seems to indicate that these disciplines are not warming to the philosophy of Design for All. The Laboratory for Information Technology Evaluation of the University of Missouri-Rolla maintains a list of “Job Opportunities in HCI/Usability”. Between mid December 2003 and mid August 2004, 99 job openings were posted to this list, including vacancies at Microsoft, Oracle, SAP, Macromedia, Adobe, AOL, Siemens and Watchfire. However, only six job descriptions mentioned accessibility or Section 508, and in four of these descriptions, experience applying Section 508 guidelines was preferred but not required.
Some organisations in the ICT industry, especially in software engineering, have a separate department for Quality Assurance. Some have argued that it may be counter-productive to maintain this dividing line between product development and QA, arguing that developers should feel responsible for the quality of their own work [Pettichord 2004; Rothman 1996]. Irrespective of how QA is organised, it makes sense to make accessibility (for people with disabilities, for temporary disabilities, for people in handicapping situations) a requirement for quality. Therefore, accessibility testing should be added to the usual range of tests (unit testing, functional testing, performance and load testing, integration testing, security, etc).
As described in the introduction, several lecturers involved in the pilots have pointed out that newly graduated students lack the necessary background to be taught Design for All, because either existing curricula are obsolete and not kept up-to-date with fast-evolving technologies, or subjects are taught narrowly focused on some aspects of the topic. What follow are examples of missing knowledge or of topics that would need a deeper analysis within university curricula in two different areas.
With this degree, students can work in different fields, e.g.:
Among the necessary knowledge that is directly or indirectly linked to DfA and people with special needs, we can highlight (for references, see Appendix B of Deliverable D1.4a):
This list is not exhaustive, but gives a generic overview of issues typically missed by the authors in newly graduated Computer Scientists.
With this degree, students can work in different fields, e.g.:
Among the necessary knowledge that is directly or indirectly linked to DfA and people with special needs, we can highlight (for references, see Appendix B of Deliverable D1.4a):
This list is not exhaustive, and some of it applies more specifically to the human factors area, but gives a generic overview of issues often omitted in the education of ergonomists and psychologists.
The conclusions of this report are in line with those of the previous report on industry needs (report D2.1), but a number of issues are now clearer. It is clear that the efforts to promote Design for All must not slacken. The low response rate to the industry survey would suggest that the co-operation between (academic) researchers and industry is not a matter of course. It has also become clearer that support from upper management is crucial to the adoption of DfA in large commercial organisations; in SMEs, especially those with a flat organisational structure, a drive from the bottom up can also work.
More research is necessary to find out what DfA-related topics are covered by professional training, and how certain knowledge sets and skills are put to use. This can influence what subjects are taught in higher education, how they are taught, and how the students' achievements are evaluated.
The survey did not uncover any subjects in professional training that do not fit in the taxonomy defined in report D3.2. The taxonomy and the additions to existing curricula suggested in section 6.3 can serve as a basis for the optimal graduate profile, but will need to be followed up by surveys of former students of courses that integrate DfA. IDCnet recommends that the EDeAN SIG on Design for All curricula could take up this work.
Card Stuart K, Moran Thomas P, Newell Alan (1983). The Psychology of Human-Computer Interaction. Hillsdale, NJ: Lawrence Erlbaum Associates.
Disability Rights Commission (2004). The Web: Access and Exclusion for Disabled People - A Formal Investigation conducted by the Disability Rights Commission. London: TSO. (Electronic versions are available at http://www.drc-gb.org/newsroom/newsdetails.asp?id=633§ion=1 and http://www-hcid.soi.city.ac.uk/rhDrc.html).
Dong, H., Keates, S. and Clarkson, J. (2003). “UK and US industrial perspectives on inclusive design.” In proceedings of Include 2003, Inclusive Design for Society and Business, 26-28 March 2003. London: Helen Hamlyn Research Centre, Royal College of Art.
Dzumba, David J. (2001). “Implementation of Inclusive Design in Industry.” [Paper.] Telecommunications: Access for All? Proceedings of the COST 219bis Seminar Leuven 3-4 December 2001. http://www.stakes.fi/cost219/procdzumba2.doc.
Graziani, Paolo. (2001). “Recommendations for Web Accessibility: current status and future developments.” Telecommunications: Access for All? Proceedings of the COST 219bis Seminar Leuven 3-4 December 2001. http://www.stakes.fi/cost219/procgraziani2.doc.
H.M. Treasury (2003a). Lambert Review of Business-University Collaboration. Summary of Consultation Responses and Emerging Issues. (This document can be downloaded via the following link: www.lambertreview.org.uk.)
H.M. Treasury (2003b). Lambert Review of Business-University Collaboration. Final Report. Norwich: HMSO. (The report can be downloaded via the following link: www.lambertreview.org.uk.)
Hudson , William (2003). “‘Public accommodation’: The US Web Accessibility Jigsaw”, SIGCHI Bulletin, January/February 2003, p. 8. http://www.acm.org/sigchi/bulletin/2003.1/janfeb03.pdf.
IEEE (2004). Guide to the Software Engineering Body of Knowledge – 2004 version. http://www.swebok.org/ironman/pdf/Swebok_Ironman_June_23_2004.pdf.
Keates, Simeon, Cherie Lebbon and John Clarkson. (2000). “Investigating Industry Attitudes to Universal Design.” Proceedings of RESNA 2000, Orlando, FL. 276-278. http://rehab-www.eng.cam.ac.uk/papers/lsk12/resna2000/.
Koivunen, Marja-Riitta. (2003). “DfA curricula needs: some experiences.” IDCnet Helsinki Workshop: “Design for All Curriculum: Towards a synergy of the needs of ICT industry and education.” 14-15 February 2003. http://www.w3.org/2003/Talks/02-IDCnet/.
Pettichord, Bret (2004). “Quality Assurance Is Not Responsible For Quality.” http://c2.com/cgi/wiki?QualityAssuranceIsNotResponsibleForQuality.
Rothman, Johanna (1996). “Software Quality Assurance: Should It Remain a Separate Organization?” SQA Quarterly, May 1996. Reproduced at http://www.jrothman.com/Papers/SQAseparate.html.
UDRP: “Universal Design Research Project.” http://www.trace.wisc.edu/docs/univ_design_res_proj/udrp.htm.
UDRP Student Survey (1998). “Universal Design Research Project: Survey of People with Universal Design Training.” http://www.trace.wisc.edu/docs/univ_design_res_proj/uwsturep.htm.
Universal Design Discussion (1996). “Universal Design: Everyone has Special Needs.” Panel Discussion at CHI 1996. CHI 96 Electronic Proceedings, edited by Ralf Bilger, Steve Guest, and Michael J. Tauber. http://www.acm.org/sigchi/chi96/proceedings/panels/Bergmann/edb_txt.htm.
“Walking the Talk. How 12 companies are leading the way towards creating a disability inclusive society” (2003). EYPD Report - December 2003. http://www.eypd2003.org/eypd/docs/walking_the_talk.pdf or http://www.eypd2003.org/eypd/docs/accessible_version_walking_the_talk.doc.
IDCnet (http://www.idcnet.info/) is a Thematic Network financed by the Information Society Technologies Programme of the European Commission (IST-2001-38786).
The strategic goal of IDCnet is to integrate information and identify core knowledge sets and skills for model curricula in Design for All for Information and Communication Products, Systems and Services. IDCnet situates its activities in the multidisciplinary area of design, especially design for, and supported by, information and communication technologies.
The goal of this survey is to assess industry needs with regard to graduate profiles for Design for All in ICT-related jobs. The survey is primarily aimed at companies that develop software, web sites or e-learning products or services, and that have expertise in accessibility, human-computer interaction, user-centred design or a related field. In addition, a number of consultancies (especially usability consultancies) will also be contacted. The results of this survey will be incorporated in a report on “The optimal graduate profile for DfA based on the needs of industry and the possibilities of within educational institutions”, which will be available at http://www.idcnet.info/documents before the end of May.
The information gathered through this survey will be used to help describe the needs of the industry in general; details about specific companies will be treated in strict confidence and will not be published without explicit permission.
You can fill in this version of the survey and mail or fax it to Christophe Strobbe (see contact details below) or fill in the online version at: http://canada.esat.kuleuven.ac.be/idcnet/WP2_NeedsOfIndustry/survey.asp.
Christophe Strobbe
Dept. Elektrotechniek - ESAT - SCD
Kasteelpark Arenberg 10
B-3001 Leuven - Heverlee (Belgium)
FAX: +32 16 32 85 39
e-mail: Christophe.Strobbe@esat.kuleuven.ac.be
This section contains examples of job vacancies that require knowledge of and/or experience with accessibility, assistive technologies, people with disabilities and/or user-centred design.
| Job Title | Alternate Format Production Specialist (Administrative Analyst/Specialist, Non-Exempt) |
| Classification | Administrative Analyst/Specialist - Non Exempt |
| Department | Disabled Student Services |
| Sub-Division | Associate VP Student Affairs |
| Salary Range | $1,473 - $2,356 per month. This is a 20 hours per week, fiscal year renewal position to end on or before 06/30/05 with a possibility of a renewal if program needs exist. |
| Appointment Type | Fiscal Year Renewal |
| Time Base | Part-Time |
| Work Schedule | TBD |
| Job Summary | Responsible for converting printed materials into electronic text (e-text), Braille, digital audio text, large print, and tactile graphics to accommodate students with disabilities. Evaluates print materials for the best conversion method. Prepares print materials for electronic file conversion. Scans and recognizes (OCR) print materials into electronic files. Edits and coordinates editing of the electronic files. Organizes edited electronic files as per the established file structure. Performs quality control checks. Copies completed electronic files to portable and stationary storage media. Labels and maintains an archive and database of completed alternate format titles. Maintains workflow tracking and archiving records to generate program reports. Other duties as assigned. |
| Essential Qualifications | Baccalaureate degree and/or equivalent experience and education sufficient to provide the knowledge skills, and abilities necessary to successfully perform the duties and responsibilities of the position as described above. Strong general computer skills (Windows), Strong skills in Word, Excel, Access, Power Point. Strong computer imaging (scanning) and computer image editing skills. Strong optical character recognition (OCR) software skills. Good professional publishing software skills. Good digital audio text software production skills. Good Braille translation and tactile graphics software skills. Good database management skills. |
Company XYZ is a leading worldwide provider of solutions and services for the management of IT infrastructure, business information and application development. We are currently looking for a qualified Sr. UI Designer/Accessibility Expert to join our Technical Architecture Team at our world headquarters.
As an Accessibility Expert you will serve as the lead UI designer responsible for establishing standards to ensure products are compliant with government policies and industry conventions regarding software accessibility. You will perform research in the tools and technology that can be used to make software accessible to users with disabilities. Develop checklists and metrics to quantify compliance with accessibility standards and perform product accessibility evaluations. Qualified candidates will also develop plans to educate development teams in accessibility design and UCD principles. Participate in industry forums and organizations regarding accessibility issues. Accessibility experts ensure all product designs meet usability objectives and user requirements. This includes project planning, recruitment, logistics, conducting evaluations, analyzing results, documenting issues, and proposing and prioritizing recommendations. Educate development and product management in UCD principles. Generalize design techniques to apply and contribute to corporate UI standards and consistency with other products. Successful candidates will also plan and perform usability activities. This includes project planning, recruitment, logistics, conducting evaluations, analyzing results, documenting issues, and proposing and prioritizing recommendations.
The qualified candidate must have 5+ years experience in UI design demonstrating expertise in accessibility design. Expert knowledge in third party tool, adaptive technology, W3C Web Accessibility Initiatives and UI design implications derived from legislative and governmental regulations. Proficiency in usability testing and methodologies is strongly preferred. Expert knowledge in Window OS, HTML, JavaScript, Java and graphic and prototyping tools.
We offer a competitive salary, 401(k), profit sharing, company sponsored medical, dental and vision coverage, employee stock purchase program, tuition reimbursement, veterinary care insurance, vacation/holidays, and complimentary breakfast daily. To learn more about CA and this opportunity, we welcome you to visit our web site at ca.com.
Responsibilities
This individual will use standard software tools to develop prototypes for the purpose of usability evaluation. Duties will include working with human factors engineer to understand user profile, process flows, and system design; layout and prototyping effective user interfaces; constructing rapid prototypes, mockups, and interaction requirements specifications; documenting the user interface design; assisting in creating usability studies and making recommendations based on findings; and other duties as assigned.
Requirements
Preferences
Job Title: Software Development Engineer/Test
Job Category: Software Development
Product: (Not Product Specific)
Travel Required:
Do you want to be on the cutting edge of automated UI testing? How about helping to improve assistive technologies for people with disabilities while you’re at it?
Come join the Accessibility team and help ship the newest and most robust UI Automation ever. UI Automation team is looking for an experienced Software design Engineer / Tester for those APIs who has a passion for finding bugs, and proven success in API testing. They should also be able to represent the tester as a customer, clearly articulating the priorities and scenarios that a test developer encounters in their day-to-day work. If you are an experienced Software design Engineer in test with a passion for technology and are experienced with complex systems, we need you!
Responsibilities include writing test plans, test cases, maintaining existing test suites, developing new tests to cover test holes or new features and automating test suites. This person should work closely with the developers, program managers and other testers to ensure quality of owned components. We work with many test teams and feature teams across Microsoft, so excellent communication and collaboration skills are a must. This person will also need to ramp up quickly on new technologies. Technically, this position requires solid C++, C# coding, understanding of the .NET framework, and experience with Windows debugging.
Experience with any of the following is a plus: Microsoft Active Accessibility; assistive technology (especially speech input or text-to-speech programs); automated test harness development.
Job Title: Software Development Engineering Lead
Job Category: Software Development
Product: (Not Product Specific)
Travel Required:
The Accessible Technology Group is looking for a lead software engineer to help architect and build the applications that will allow users with disabilities to use a new technology. You will drive the design, and assist in writing, screen-reader, on-screen keyboard and screen magnification applications as well as a personalization wizard. In addition you will design and guide the development of tools used by application framework developers to help test the accessibility of those components. You will work closely with the Development Manager to ensure that the accessibility applications deliver a great out-of-box experience for people with disabilities and that the underlying UI Automation technology is rich enough for 3rd party assistive technology vendors to deliver enhanced versions of these accessibility aids.
Qualifications for this position include a solid background in GUI software development with 5+ years of experience in C++/C# and object-oriented programming and design. You should have experience with managed code design and development. Other requirements for this position include the ability to write clear, maintainable, performance-sensitive, secure, globalization-ready code; a passion for UI or HCI design; excellent communication and collaboration skills; demonstrated technical leadership; and the ability to work both independently and in a team environment. A BA/BS degree in Computer Science or related technical discipline is preferred.