BS8878 Web Accessibility Code of Practice
Upcoming SlideShare
Loading in...5
×
 

BS8878 Web Accessibility Code of Practice

on

  • 10,210 views

 

Statistics

Views

Total Views
10,210
Views on SlideShare
10,193
Embed Views
17

Actions

Likes
5
Downloads
17
Comments
1

1 Embed 17

https://twitter.com 17

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • BCAB is a lively community of blind and partially sighted computer users. We offer training, discussion, networking and help to all our members.
  • BSI was founded in 1901, and is the national standards body for the UK.
  • BS8878 defines a process for creating and implementing an eAccessibility strategy within an organisation.
  • BS8878 defines a process for creating and implementing an eAccessibility strategy within an organisation.
  • BS8878 is a process for creating an organisational strategy, so it can be used in harmony with other technical guidelines and in support of legal obligations.
  • Increasingly people were using mobile, tablet and even TV or console based devices to access the web.
  • Increasingly the public and private sectors were moving towards "digital by default", a phrase since championed by UK government.
  • The Equality Act was being written, and the law was being brought up to date with regard to digital services.
  • BS8878 was written by people with experience of creating and implementing eAccessibility strategies within different organisations.
  • BS8878 was written by people with experience of creating and implementing eAccessibility strategies within different organisations.
  • BS8878 was written by people with disabilities, and by people with experience of working with different user groups.
  • The research showed that websites were under performing, and that no official processes existed to help website owners strategically implement accessibility.
  • The research showed that websites were under performing, and that no official processes existed to help website owners strategically implement accessibility.
  • PAS 78 was a non technical guide to using standards to build accessibility into the development lifecycle.
  • The information in PAS 78 was becoming dated, and the aim was to bring it in line with current thinking as well as to transition it into a fully fledged UK standard.
  • There was a considerable response from the wider accessibility community, and the resulting comments were used to adapt and refine BS8878 as it evolved.
  • The response was again considerable, and feedback suggested that BS8878 was coming together as an effective standard.
  • BS8878 was officially launched in London, and was given a positive reception by all those who attended the event.
  • The role or department should have responsibility for compliance with BS8878, and should consider the organisation's legal obligations as well as the business benefits of accessibility.
  • The policy should define a default position for all web products, including compliance with web accessibility guidelines, degree of user experience, and the platforms and technologies that will be supported.
  • A web product might be a rich internet application, browser based cloud service, software as a service, or an internet enabled widget.
  • Each web product should have its own policy that documents the research, strategic decisions and implementation of accessibility throughout its lifecycle.
  • A web product policy follows the process through research and requirements, strategic choices, procurement, production, evaluation, and post launch.
  • The purpose of the web product will have an impact on the way accessibility is considered. Some web products may be more challenging than others.
  • The web product may be target at a particular audience (for example students, musicians or patients), or it may have a limited audience (an intranet for example).
  • Desktop or ethnographic research will provide solid information about the web product's target audiences, and will help inform decisions made later in the process.
  • Internal audiences may be constrained in their technology choices by in-house policies, and general audiences may be constrained because of cost, uncertainty or availability of technology.
  • Where a web product is available to the public it may be that accessibility is considered in terms of broad user groups, or it may be possible for individuals to make choices about the way they receive the web product.
  • Defining and prioritising the web product's goals will help ensure that the web product is designed to enable its target audiences to achieve those goals.
  • The web product is likely to offer different levels of user experience, based on different audience groups and goals.
  • The web product may follow an inclusive design approach (based on existing guidelines and standards), facilitate product adaptation (enabling people to personalise their experience), or a combination of both.
  • The web product may be optimised for desktop and assumed to work on alternative platforms, be designed to be responsive to different delivery platforms, or be split into a suite of purpose built alternative versions.
  • The web product is likely to support different operating systems, browsers and assistive technologies, based on its target audience and their requirements.
  • The choice of in-house development or third party procurement will be influenced by capability, resources, budget and timetable.
  • The core technologies used to create a web product should be capable of meeting accessibility goals, and should have a good level of assistive technology support.
  • The accessibility guidelines should be the most appropriate for the web product (WCAG 2.0 or Section 508 for example), and where applicable a specific conformance level should be identified.
  • An accessibility test plan should be created and implemented throughout production, either by the in-house development team or by a third party supplier.
  • The decisions, justifications and key points of the web product's policy should be presented as an accessibility statement available from the web product itself.
  • Make sure any outstanding work is completed on the web product, then put in place a plan to stay on top of accessibility as new content and features are added to it.
  • BS8878 provides useful information about a range of guidelines that may be applied to web products.
  • BS8878 provides useful information about the practicalities of each step within the process.
  • BS8878 includes information covering UK law, user testing, the business case for accessibility, measuring user success, procurement, and handling feedback from users, as well as example policy documentation.
  • Information about the law, and examples of user demographics, technology preferences and other aspects of BS8878 are provided for a UK audience.
  • BS8878 is a process. It assigns responsibility for accessibility, and advocates a research based methodology for making accessibility part of "business as usual" within an organisation. The core principles of BS8878 can be taken out of the UK specific supporting information, and applied within any organisation in the world.
  • Jonathan Hasseel will look at how BS8878 has helped UK organisations (such as the Royal Mail) take a better approach to eAccessibility.
  • Jonathan Hasseel will look at how BS8878 has helped UK organisations (such as the Royal Mail) take a better approach to eAccessibility.

BS8878 Web Accessibility Code of Practice BS8878 Web Accessibility Code of Practice Presentation Transcript

  • BS8878 Web Accessibility Code of Practice Leonie Watson Chair of the British Computer Association of the Blind (BCAB) @WeAreBCAB @LeonieWatson
  • What is BS8878?
  • It’s a UK national standard
    • From the British Standards Institution (BSI).
  • It’s a framework
    • For making eAccessibility “business as usual” within an organisation.
  • It’s not a substitute
    • For existing legislation, guidelines or standards.
  • Why was BS8878 created?
  • The changing technological landscape
    • It could no longer be assumed that people were accessing the web from a desktop.
  • The changing political landscape
    • "Promoting digital inclusion is essential for a dynamic modern economy and can help to make government more efficient and effective.“
    • (David Cameron)
  • The changing legal landscape
    • The Equality Act would replace the Disability Act in 2010.
  • Who wrote BS8878?
  • Industry professionals
    • People with a strong background in accessibility and digital inclusion.
  • Disability organisations
    • People with disabilities, and representatives from disability organisations.
  • How was BS8878 created?
  • In 2005...
    • Research from the Disability Rights Commission (DRC) revealed that websites were struggling with accessibility.
  • In 2006...
    • PAS 78 (Guide to good practice in commissioning accessible websites) was released.
  • In January 2008...
    • Work began to transform PAS 78 into a British Standard (BS8878)
  • In November 2008...
    • First draft of BS8878 was made available for widespread public consultation.
  • In May 2010...
    • A second draft of BS8878 was made available for public consultation, receiving international comment.
  • In December 2010...
    • BS8878 (Web Accessibility Code of Practice) was officially released.
  • How does BS8878 work?
  • Assigning responsibility
    • Responsibility for eAccesssibility should be assigned to a role or department;
    • That role or department should be empowered to fulfil that responsibility.
  • Creating an eAccessibility policy
    • A document that explains an organisation’s commitment to accessibility, and summarises its approach.
  • Introducing web products
    • Any website, web service or web application delivered over IP.
  • Creating a web product policy
    • A living document that evolves throughout the web product’s entire lifecycle;
    • Based on the intentions of the organisational policy, but tailored to a particular web product.
  • How is a web product policy created?
  • Document the accessibility journey.
  • Research and requirements
  • Step 1: Define the purpose of the web product
    • What is the purpose of the web product, and what will people expect to achieve when they use it?
  • Step 2: Define target audiences
    • Is the web product internal or public facing, and is it aimed at a particular group of people?
  • Step 3: Needs of the target audiences
    • What are the general needs of the target audiences, and do they have specific needs in relation to the web product?
  • Step 4: Platform and technology
    • Are the target audiences restricted in their technology, perhaps because of cost, confidence or compatibility?
  • Step 5: Relationship with target audiences
    • Will the web product enable personalised choices through a login or cookie, or will it support more general groups of people.?
  • Step 6: Tasks and goals
    • What are the goals someone will be able to complete, and what are the tasks they will use to achieve those goals?
  • Strategic Choices
  • Step 7: Level of user experience.
    • Will the web product offer a technically accessible, useably accessible, or enjoyably accessible experience?
  • Step 8: Accessibility approach
    • Will the web product take an inclusive design approach, offer user personalisation, or a combination of both?
  • Step 9: Delivery platform
    • Will the web product be optimised for a particular platform, or be part of a suite of platform specific versions?
  • Step 10: Target technologies
    • Which operating systems, browsers and assistive technologies will the web product support?
  • Procurement
  • Step 11: Create or procure
    • Will the web product be created in-house or procured externally, and how do you ensure third party solutions are accessible?
  • Production
  • Step 12: Web technologies
    • Do the technologies used to build the web product support accessibility, and do they expose information to assistive technologies?
  • Step 13: Web guidelines
    • What are the best accessibility standards available for the chosen technologies, and how will the web product conform to them?
  • Evaluation
  • Step 14: Assure accessibility
    • What is the accessibility test plan, and how will it be evaluated throughout development of the web product?
  • Step 15: Communicate clearly
    • What will the accessibility statement say, and how will it be made available throughout the web product?
  • Post Launch
  • Step 16: Maintaining accessibility
    • How often will updates be planned, and what is the process for continually reviewing and evaluating the web product?
  • What else does BS8878 offer?
  • Lots of helpful guidelines
    • Inclusive design guidelines;
    • Personalisation guidelines;
    • Guidelines for non computer platforms;
    • Guidelines for older people.
  • Useful advice on assuring accessibility
    • Gathering requirements;
    • Creating a test plan;
    • Testing methods;
    • Post launch programmes.
  • Even more helpful annexes
    • 15 annexes providing supporting information, guidance and example documentation.
  • Why is BS8878 a British standard?
  • Legal and cultural specifics
    • BS8878 references UK law, and contains guidance on user requirements that is culturally oriented towards UK citizens.
  • How can BS8878 be applied internationally?
  • Core principles
    • BS8878 encourages the consideration of accessibility throughout a web product’s lifecycle, and its core principles can be followed in any organisation.
  • Where can I find out more about BS8878?
  • BS8Case studies and making BS8878 international
    • Jonathan Hassell (Hassell Inclusion);
    • Friday 1.50pm, Madeleine AB 3rd floor;
    • http://www.hassellinclusion.com/bs8878/
  • Any Questions?
  • Thank you
    • Léonie Watson
    • Email: chair@bcab.org.uk
    • Twitter: @LeonieWatson
    • W. bcab.org.uk