These meetings are for everyone responsible for managing web projects at CF and are not optional.

Please familiarise yourselves with the following before the meeting:

• Draft CF accessibility guidelines
• Draft British Standard 8878 (Web accessibility – Building accessible experiences for disabled people – Code of practice)
  • Online with comments (registration required)
  • PDF/Word versions

Agenda

1. Apologies
2. Matters Arising
3. Brief project updates
4. Main focus: Accessibility
   1. Revisit draft accessibility policy with view to formalising it.
   2. Discuss steps necessary to ensure all of the organisation can apply for conformance of BSI 8878 when it’s published (probably mid-2009)
5. Share knowledge of tools, events, etc

Draft

1. Statement of commitment

   1. The Citizenship Foundation is committed to making its output as accessible as possible to all audiences (including those with visual, hearing, cognitive or motor impairments) to fulfil its mandate and to meet its statutory obligations defined by the Disability Discrimination Act.
      1. Unless it can be shown to be technically or practically impossible, all content MUST be made accessible.

2. Scope

   1. These standards relate to all public facing Citizenship Foundation websites.

3. Editorial content

   1. You MUST provide an accessible alternative to any potentially inaccessible content, including all plug-in content, UNLESS this can be proven to be technically or practically impossible.
      1. An accessible alternative is defined as one that meets the information, educational and entertainment objectives of the original content.
      2. If your content relies on Flash or other plug-ins, you MUST still provide an HTML alternative that does not rely on Flash, other plug-ins or JavaScript.
      3. All content and features delivered using JavaScript MUST be accessible with JavaScript switched off.
   2. All accessible alternative content MUST be updated in-line with and at the same time as the original content.
   3. You SHOULD divide large blocks of information into manageable chunks e.g. use short paragraphs.
   4. Lines SHOULD NOT be longer than 70 characters (for the browser default font setting) including the spaces in between words, except:
      1. where the language of the website is Arabic, German, Serbian, Russian, Persian, Urdu, Pashto, Hindi, Bengali, Sinhala, Chinese (simplified and traditional), Welsh, Polish, Ukrainian, Greek, Macedonian, Bulgarian, or Dutch;
      2. the line is a URL or code fragment.
   5. You MUST provide an appropriate text equivalent for each non-text element of the core content. See the Textual Equivalents Standards.
   6. You SHOULD specify the expansion of each abbreviation or acronym in a document where it first occurs.
   7. All pages MUST use heading elements. (See the BBC’s Semantic Mark-up Standard (eventually I hope to develop one for the Citizenship Foundation).)
   8. You MUST use HTML text rather than images wherever possible.

4. Language/Style

   1. You SHOULD use plain language and avoid jargon.
   2. Where the language in the document changes (e.g. from English to Welsh), you MUST indicate this with a tag containing a Lang attribute.
   3. All text of more than two lines MUST be left aligned (if published language is naturally ranged left e.g. English), except for tabular data and where the formatting is integral to the meaning of the text, e.g. poetry.

5. Editorial Images

   1. Editorial content MUST make sense without reference to images or diagrams, UNLESS the subject matter can only be displayed via images (e.g. a ’spot the difference’ game).
      b. Instructional images MUST make sense without text e.g. a user must be able to follow a set of diagrammatical instructions without the help of a text explanation.
   2. You MAY support instructions with diagrams.
   3. Where appropriate, you SHOULD use pictures and symbols in addition to text.
   4. You SHOULD support your “calls to action” with icons.
   5. You MUST NOT use ASCII art. (You’re unlikely to want to, but just in case!)
   6. You SHOULD ONLY use symbols (e.g. < or >) in content for their semantic use (rather than, for example, using >> as a fast forward button).

6. Structure/Function/Layout

   1. You MUST provide consistent navigation - see Page Layout Standards.
   2. You MUST clearly define the different sections of the page and ensure consistent location of screen objects - see Page Layout Standards.
   3. All text based content SHOULD be published on a plain solid background.
   4. You MUST NOT create periodically auto-refreshing pages in their default state, i.e. you can allow an opt-in auto-refresh.
   5. You MUST NOT break browser back button functionality.
   6. New windows MUST NOT be opened from a page UNLESS they are pop-up (this is inconsistent on CF corporate site)
   7. You MUST clearly label links (in the text of the page) which launch pop-ups so that the audience know they are launching a pop-up.
   8. Pop-ups MUST NOT appear without being intentionally opened by the user.

7. Movement

   1. You MUST NOT cause an item on the screen to flicker - see Flicker Guidelines.
   2. You MUST NOT use blinking, flickering or flashing objects.
   3. You MUST provide a mechanism to freeze any movement on the page UNLESS there is no alternative to the movement.

8. Audio and Video Content (A/V)

   1. You SHOULD provide subtitles/captions that can be turned off and on for AV content (including AV content featured in interactive features or games), unless you have evidence that the business costs are a risk to the success of the project’s fruition.

9. Frames

   1. You SHOULD avoid using frames
   2. You MUST describe the purpose of frames and how they relate to each other if this is not obvious using the frame titles alone.

10. Forms

    1. Forms MUST be navigable using the keyboard. In particular, you should beware of putting onChange instructions on a select box (dropdown list) using javascript.
       1. A keyboard user trying to navigate the options in the select box may automatically be taken to their first selection (keystroke) rather than their desired selection, if onChange instructions are used.
    2. You MUST provide a “submit” button on all forms.
    3. In the future we may look at creating guidance for accessible forms. In the meantime, please refer to the following:
    1. • Creating Accessible Forms on the Stanford University Accessibility Program website.
       • HTML/XHTML Accessible Forms Tutorial on the Web Standards Project website.
    2. Refer also to the BBC’s Semantic Mark-up Standard for further information about forms (eventually I hope to develop one for the Citizenship Foundation).

11. Documents

    1. All downloadable documents including PDFs MUST be made available in alternative accessible formats, either HTML or Text.
    2. All PDFs MUST comply with PDF Accesibility Guidelines.

12. Links

    1. Where possible all pages SHOULD provide users with the option to bypass groups of related links e.g. “Skip to Content”, “Skip to Local Navigation” and “Skip to Global Navigation”. This option SHOULD be the first thing found by screen readers i.e. first thing inside the body tag.
       1. “Skip to Content”
       2. “Skip to Global Navigation”
       3. “Skip to Page Navigation”
    2. You SHOULD try and avoid using image maps
    3. You MUST provide redundant text links for each active region of an image map.
    4. All links to video content SHOULD be accompanied by an image that encapsulates what the programme is or is about.

13. Accessibility Options

    1. Page layout MUST accommodate the enlarging of text.
    2. You MUST use style sheets to control layout and presentation.
    3. You MUST NOT use tables for non-tabular data/content, or presentational markup, e.g. font tags. Refer also to the BBC’s Semantic Mark-up Standard (eventually I hope to develop one for the Citizenship Foundation).

Priority 1 (required for AA)

• None

Priority 2 (required for AA)

• Metadata missing (See WCAG metadata explanation)

Priority 3 (optional for AA)

For useful information (documents, guideance, law, etc) see web accessibility links.

Browser tools

• Opera developer tools (built into Opera 9.5 +)
• Taw: web accessibility test (Firefox Add-on)
• Web Developer toolbar (Firefox Add-on)

Assistive tools (for emulating user experience)

• Thunder: screen reader (download)
• WebbIE: text browser (download)

Tests and validators

• Accessibility Valet Demonstrator (online)
  
• Cynthia Says: Web accessibility validator (online)
• Taw: web accessibility test (online)
• WAVE: accessibility evaluation tool (online)

• Designing the Moment: Web Interface Design Concepts in Action
  Robert Hoekman, New Riders
• Groundswell: Winning in a World Transformed by Social Technologies
  Charlene Li & Josh Bernoff, Harvard Business Press
• Radically Transparent: Monitoring and Managing Reputations Online
  Beal Strauss, Sybex
• Search Engine Optimization: An Hour a Day
  Grappone/Couzin, Sybex
• Tagging: People-Powered Metadata for the Social Web
  Gene Smith, New Riders
• Web 2.0: A Strategy Guide: Business thinking and strategies behind successful Web 2.0 implementations
  Amy Shaun, O’Reilly

• CF news area (http://tinyurl.com/5633wl)
• CF events calendar (http://tinyurl.com/6kd5yp)
• Citizenship education Google calendar (http://tinyurl.com/6kd5yp)
• Facebook (http://tinyurl.com/67qcxj)
• Twitter (twitter.com/citizenship)
• YouTube (http://tinyurl.com/62svu5)

Currently it is populated once an hour via a feed from TwitterFeed, which in turn is fed by a Yahoo! Pipe that amalgamates a number of our feeds (eg CF news, CF blog posts, Diversity and Dialogue).