Page tree
Skip to end of metadata
Go to start of metadata

written October 2014

Clear statement of intent

  • Have a clear way of reporting a problem with accessibility on the website - e.g. http://www.stanford.edu/site/accessibility
  • Have a simple policy / declaration that states our intention to make all pages valid (xhtml/html 5) and conform to WCAG level AA - outline here our approach to satisfying the core values of WCAG 2.0
    1. Perceivable
    2. Operable
    3. Understandable
    4. Robust
  • Have a list of supported technologies (ie those the site with which the site has been tested)
  • Link this information up with physical accessibility information
  • If relevant, include links to any research conducted here

Changes to our current site

  • Rewrite the print stylesheet in the v3 and Foundation template
  • Remove BETSIE link from common template - possibly replace with link to report accessibility issue
  • Remove text resizing from common template - this can and should be done by the browser or the assistive technology employed by the user

Internal process

There is a lot we can and should do. These are suggestions for first steps

  • Adopt some HTML / CSS guidelines for accessibility, such as oocss in Github
  • Scan collections of key pages and have the results alert us to problems, as we do with 404s
  • Adopt a browser tool for site design and development (particularly for use by Design and Content - the HTML Code Sniffer bookmarklet seems like a good option)
  • Mobile testing should include accessibility testing - space around links as targets, etc, the page needs to do more than lay out correctly
  • Create a group of users of assistive technology who periodically (monthly?) test some pages and report on any problems they encounter which we can then fix (Tim Winship has offered to set this group up)

Team learning

  • We have very little knowledge of screen readers within the team. A basic understanding of the technology and what it presents to the users would greatly enhance our ability to create pages which work correctly with them. A basic training course, or just some time (an afternoon) set aside for us to make use of a screen reader would make a start.
  • Mobile accessibility / usability is a new field and a largely unknown one for us. There are some checks we can assume (does it work, can it be read, are the targets big enough to hit with your fingers reliably) but we don't know what "good enough" looks like and there are other questions which we should consider when looking at mobile devices (limitations on bandwidth and battery power, for instance). There are W3C recommendations for mobile web best practices which should be read and considered for adoption into our processes. There is also this good compilation of the guidelines in use by other groups, although it is a few years old.