370 likes | 460 Views
The Web: Access and Inclusion for Disabled People Helen Petrie Centre for Human Computer Interaction Design City University London. Aims of the Formal Investigation. 1. Systematically evaluate accessibility of the Web in Great Britain 2. Analyse recurrent barriers to Web accessibility
E N D
The Web: Access and Inclusion for Disabled PeopleHelen PetrieCentre for Human ComputerInteraction Design City University London
Aims of the Formal Investigation 1. Systematically evaluate accessibility of the Web in Great Britain 2. Analyse recurrent barriers to Web accessibility 3. Make recommendations for further work which will contribute towards enabling disabled people to enjoy full access to, and use of, the Web
Aim 1: Systematically evaluate the accessibility of the Web in Great Britain
User Panel Established User Panel of 50 disabled people • Blind • Partially sighted • Deaf and hard of hearing • Dyslexic • Physically impaired Wide range of ages, gender, ethnicity, geographic location, experience with Web, assistive technologies used in accessing the Web Conducted interviews, focus groups, live Web sessions
Sample of 1000 websites Took a representative sample of 1000 Websites of interest and importance to disabled people in Great Britain Five main categories: • Government and information • Businesses (SMEs to multinationals) • E-commerce (banking, travel, retail…) • Entertainment and leisure • Web services (ISPs, portals, search engines, chat rooms …)
Automated testing of the home pages of the 1000 Websites Criteria: the W3C Web Content Accessibility Guidelines (WCAG version 1.0) Tested only those items in the Guidelines which can be checked automatically (13 out of 65 Checkpoints)
Results of automated testing 19% of home pages (192) passed the automatic Priority 1 checks, so less than 19% would be fully Priority 1 compliant (A Conformance) 32.2% of government/information Website home pages passed automatic Priority 1 checks No other differences between the sectors
only 6 (0.6%) of home pages passed Priority 1 + Priority 2 automatic checks But only 2 (0.2%) passed both automatic and manual checks at Priority 1 + 2 checks (AA conformance) No home pages passed Priority 1 + Priority 2 + Priority 3 (even automatic checks) (AAA conformance) Conclusion: basic technical accessibility very poor
In-depth testing of 100 Websites Selected 100 Websites from the sample of 1000 on the basis of a number of measures: • the 5 categories • use of different Web technologies • accessibility level on automated testing
Automated testing of whole site or the first 500 pages in the site In total we have conducted automated testing on approximately 39,000 Web pages By far the largest and most comprehensive study of Website accessibility ever undertaken
User evaluations Testing whether sites conform to the WAI Guidelines is important, but what we are really trying to achieve is Websites that disabled people can use So wanted to compare the results from the automated testing with user evaluations - getting the User Panel to undertake real tasks on the Web in realistic situations
Evaluation procedure First session: at our lab, with researcher next to the user Procedure: • free exploration • 2 representative tasks for the site (e.g. find out current interest rate) • questions from the researcher (rating scales, open ended) Evaluated 2 - 3 Web sites this way
Users then used the same procedure in their own time [“homework” - at home, office…] evaluated 7 - 8 other Websites for homework each member of the User Panel evaluated 10 Websites in total target was 1000 tasks = 50 users x 100 sites x 2 tasks per site 913 tasks attempted, logged and analysed
Success at tasks Overall, panel members were successful on only 76% of the tasks but also significant differences between impairment groups: • Blind successful 53% • Partially sighted 76% • Dyslexic 83% • Hearing impaired/physically impaired 85% So, blind Panel members unable to complete nearly half the tasks
Problems the users encountered 585 problems were encountered in undertaking the tasks 55% (319) related to the WAI Checkpoints, but 45% (266) did not Need to use the Guidelines, a site which violates them will definitely not be accessible, but currently also need user testing Guidelines are necessary but not sufficient
Of the 55% (319) problems related to the WAI Checkpoints: 8 WAI Checkpoints accounted for 82% (262) of these (45% of all 585 problems identified)
If developers would address these 8 issues, the Web would be a lot more accessible and usable for disabled people These 8 Checkpoints should form the bedrock of Web design They are not enormously difficult and they do not inhibit creativity or innovation in Web design
The accessibility gap and the usability bonus Controlled study of six websites to see how disenfranchised blind people are on the web • Three sites with high technical accessibility • Three sites with low technical accessibility Time blind and sighted users take to undertake representative tasks
For the sighted/non disabled users: Average task time High accessibility sites 36 seconds Low accessibility sites 52 seconds 35% faster on high accessibility sites Conclusion: Accessible sites are also usable sites
The good news for website developers (and owners) The benefits of addressing accessibility issues - you also address the usability issues “Extreme” Web site testing - test your site with disabled users and you will deal with accessibility and usability
Aim 2: Analyse recurrent barriers to Web accessibility
Survey of website owners and website developers Sent questionnaires to 712 website owners in public and private sectors • randomly selected • 89 questionnaires returned [suggests a level of apathy in itself?] Interviewed 21 website owners and 25 website developers • also randomly selected
Results from Website owners Large organizations seemed to be well aware of the issues of Web accessibility and their responsibilities under the DDA 68% said they took accessibility into account when commissioning their Website (unfortunately it doesn’t seem to have had much effect) SMEs less aware of the topics only 29% said they took accessibility into account
Perceived barriers • Cost (money, time, staff resources) • Low level of knowledge of the issues and how to address them Myths of Web accessibility: • incompatibility between sophisticated Websites and accessibility • incompatibility between creativity/ innovation on the Web and accessibility
Results from Website developers 80% said they attempted to develop accessible Websites at least some of the time Reported lack of interest by commissioners of Websites [doesn’t really match results from website owners] Best argument with clients for accessibility is increased in potential audience for the Website Level of expertise low: only 9% claimed any sort of expertise
Conclusions • Current state of Website accessibility is poor • Blind people are the most disenfranchised • Doing 8 things will make a big difference to accessibility of the Web • Automated testing necessary but not sufficient • User involvement is very important - will address both accessibility and usability • Awareness and training for Web developers and Website owners is vital
Many thanks to the research team … In alphabetical order: Christine Booth, Wendy Fisher, Kulvinder Gill, Fraser Hamilton, Neil King, Terry Hoi-Ya Ma, Claire Paterson and Panayiotis Zaphiris
More detailed information about the Formal Investigation can be found at: www-hcid.soi.city.ac.uk/rhDrc.html or contact me at: h.l.petrie@city.ac.uk
Web Content Accessibility Guidelines (WCAG) Version 1.0 (Version 2.0 in development) 14 Guidelines Divided into 65 checkpoints • 13 can be checked automatically by computer (e.g. images in a web site have ALT text) • 52 need human judgement (e.g. do not rely on colour alone to convey information)
Web Content Accessibility Guidelines (WCAG) Priority 1 – A Web content developer must satisfy this checkpoint. Otherwise one or more groups will find it impossible to access information … Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents. Priority 2 – A Web content developer should satisfy this checkpoint. Otherwise one of more groups will find it difficult to access information … Satisfying this checkpoint will remove significant barriers to accessing Web documents. Priority 3 – A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information …. Satisfying this checkpoint will improve access to Web documents.
Checkpoints accounting for most problems 1.1 Provide a text equivalent for every non-text element 2.2Ensure that foreground and background colour combinations provide sufficient contrast 6.3Ensure that pages are usable when scripts, applets and other programmatic objects are turned off 7.3Until user agents allow users to freeze moving content, avoid movement in pages
10.1 Until user agents (=browsers, assistive technologies) allow users to turn off spawned windows, do not cause pop-ups or other windows to appear … 12.3Divide large blocks of information into more manageable groups where natural and appropriate 13.1 Clearly identify the target of each link 14.1Use the clearest and simplest language appropriate for a site’s content
Problems experienced by blind users Incompatibility between screenreading software and web pages (26) Incorrect or non-existent labelling of links, form elements and frames (24) Cluttered and complex page structures (23) ALT tags on images non-existent or unhelpful (16) Confusing and disorienting navigation mechanisms (16)
Problems experienced by partially sighted users Inappropriate use of colours and poor contrast between content and background (20) Incompatibiity between assistive technology (e.g. for magnification) and web pages (19) Unclear and confusing layout of pages (18) Confusing and disorienting layout of pages (18) Confusing and disorienting navigation mechanisms (16) Graphics and text size too small (10)
Problems experienced by physically impaired users Confusing and disorienting navigation mechanisms (20) Unclear and confusing layout of pages (19) Graphics and text size too small (11) Inappropriate use of colours and poor contrast between content and background (10)
Problems experienced by Deaf/hearing impaired users Unclear and confusing layout of pages (23) Confusing and disorienting navigation mechanisms (12) Lack of alternative media for audio-based information and complex terms/language (10) Inappropriate use of colours and poor contrast between content and background (9) Graphics and text size too small (9)
Problems experienced by dyslexic users Unclear and confusing layout of pages (41) Confusing and disorienting navigation mechanisms (32) Inappropriate use of colours and poor contrast between content and background (20) Graphics and text size too small (14) Complicated language or terminology (7)