Access 8878: Web Accessibility - Code of Practice

Get BS 8878BSI Logo (this link will open in a new browser window)

Assuring Accessibility

BS 8878 provides us with a comprehensive approach to developing and maintaining accessibility throughout the product lifecycle.

The standard requires organizations to consider and document accessibility decisions at each stage of development:

  1. 8.1 Summary of approach
  2. 8.2 Gathering requirements from disabled users
  3. 8.3 Creating an accessibility test plan
  4. 8.4 Accessibility testing methods
    1. 8.4.1 Summary of accessibility testing methods
    2. 8.4.2 Validation testing of markup
    3. 8.4.3 Manual conformity testing
    4. 8.4.4 Testing with assistive technologies and browser O/S settings
    5. 8.4.5 "Expert Review" - Heuristic evaluations and cognitive walkthroughs
    6. 8.4.6 User testing with disabled and older people
    7. 8.4.7 Automated WCAG conformity testing
  5. 8.5 Post launch programme of accessibility testing

8.1 Summary of approach

The organization should ensure that the needs of disabled people and older people are gathered at the start of the development process. Developers need to be informed about the needs of groups of users with specific disabilities. Conformance with BS 8878 doesn't permit a build-now-test-later approach to accessibility, but requires that the needs of disabled users are considered throughout the product lifecycle.

The BS 8878 document (this link will open in a new browser window) provides some personas that can help developers think about how to meet specific

Access 8878 are developing additional "personas" that can be used to gain a better understanding of specific user requirements relating to their disability. (future link)

BS 8878 states that:

Organizations should integrate accessibility assurance throughout a product's lifecycle as follows.

  • Initial production conception and requirements analysis: Ensure that the needs of disabled and older people are gathered whilst defining the web product's requirements specification (see 8.2).
  • Procurement or production: Ensure that an accessibility test plan (see 8.3) is created and adhered to for the design, prototyping and build parts of the product's lifecycle. This is to ensure the web product created upholds the degree of user-experience the organization has decided to aim to provide (see 6.7) on its launch.
  • Post-launch maintenance: Ensure that all post-launch maintenance and updates of the web product are tested to ensure the product continues to uphold that degree of user-experience (see 8.5).

8.2 Gathering requirements from disabled users

It's important that you gather data from individuals with disabilities with regards to your web product proposal, but the exact approach you take will depend on a number of factors:

  • whether there an existing version of the web product that people can review
  • if there is an existing web product that is similar enough in nature that people can express their opinions in a valuable way
  • if the web product is new, to discuss with them what they feel their requirements may be and how it might fit into their lifestyle.

BS 8878 notes that if ethnographic research is undertaken to generate a representative sample of the target audience, that this includes disabled and older users and that their requirements are captured accurately.

It should be noted while gathering user requirements that the needs of individuals can vary significantly even when people appear to have very similar disabilities. This is often due to factors such as:

  • Technology preference
  • Differences in browsing habits
  • Skill levels and experience of using assistive technologies
  • Differences in anticipated behaviour of the web product
  • Confidence with the computer or other device
  • Cognitive ability

If can sometimes be difficult to make conclusions based on user testing results that will sometimes produce conflicting information, particularly if the reasons for the difference in testing results aren't clear.

In these circumstances it can be useful to talk to a specialist in web accessibility, or to refer to WCAG 2.0 guidelines.

8.3 Creating an accessibility test plan

BS 8878 states:

Where an organization is procuring the web product, or commissioning its production out to a third party, this accessibility test plan will be a crucial document in allowing the organization to specify what sort of evidence they will require for formal acceptance that the web product upholds the degree of user-experience they have specified.

Organizations are strongly advised to harmonize their usability and accessibility test plans for a product. It makes good financial and logistical sense to conduct any usability testing with disabled and older people alongside usability testing of more general audiences.

The test plan should clearly state:

  • which accessibility testing methods (link int) will be used, at what points of the web production process (see 8.4.1 for a guide);
  • how the methods will support the production team in assuring progress towards the target degree of user-experience;
  • how the test results will be documented; and
  • how the test results will be fed back into the web production process to improve the web product.

ACCESS 8878 provides a discussion about the different testing methods proposed by BS 8878

Access 8878 is the leading resource for BS 8878

Web Accessibility – Code of Practice Access 8878 is the leading resource for BS 8878 (this link will open in a new browser window)Cookies Policy