Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.


Quick Start Guides/Requirements Analysis

From Education & Outreach
Jump to: navigation, search

Updates

Note: At the EO meeting of 1st May 2015 it was agreed to use an activity or task based approach rather than a role based approach, for example Designing instead of Designer.

Purpose

Provide introductory tips for people involved in website creation and maintenance, who are new to accessibility.

Objectives

  1. Help ease readers into accessibility.
  2. Provide tips based on audience role, e.g. designer.
  3. Provide practical and actionable tips that will help readers improve the accessibility of their deliverables.
  4. Avoid overwhelming users with too much information, but ensure they have enough to understand what they need to do.
  5. Direct readers to additional more in-depth resources.
  6. Provide a reminder for those who have a little bit more experience.
  7. Provide a resource for advocates, trainers, and consultants to direct people to.

Approach

The tips will be introductory in nature and will assume little or no background knowledge of accessibility.

As much as possible, language will be in layman's terms. Where possible, use language from the "Understanding" sections of Success Criteria.

There will be an overview page that will provide access to each of the set of tips.

Each set of tips will present between seven and ten succinct, practical, and actionable statements, e.g. 'Ensure all images have appropriate alternative text'.

Each tip will also include short descriptive text that explains how this tip can be achieved. The description should avoid too much explanations of why this tip is important. Additionally, an illustrative example where appropriate, and links, with a short explanation, to related resources that will expand upon the activity, e.g. Images tutorial. Where appropriate, the tip will include additional benefits that it brings.

Each set of tips should include a final tip that points to more in-depth resources on accessibility. Ideally it should also clarify that this is not an exhaustive list of issues for accessibility.

Criteria for Tips

Criteria:

Considerations for potential tips:

  • How relevant is this tip to the purpose of this resource? (getting started tips, not comprehensive guidance or even the most important things)
  • How often do you think that this issue occurs in practice?
  • How much of an impact does the tip have on real-world accessibility?
  • How relevant is the tip to this task versus other tasks? (e.g., Designing versus Writing)
  • What is the priority of this tip related to the other tips?



Archived Info

Suggested Audiences

  • Designer
  • Developer
  • Author
  • Advocate
  • Project Manager

Example

Role

Designer

Tips

  • Ensure color palette is high contrast
    Providing good contrast between foreground and background colors is important for some people with color discrimination difficulties and can also help some people with some form of learning disability, such as dyslexia. Tools are available to help you check and tweak your color choices until the right balance is reached.
    Related information
    Mr. Lee, Online shopper with color blindness
    Evaluation Tools List
    Contrast (Minimum): Understanding SC 1.4.3
    Also helps with...
    Mobile and tablet users who are in varying lighting conditions.
  • Don't use color alone to signify meaning
  • Ensure links and interactive elements have a hover and focus styling
  • Provide navigation that allows easy access to other website pages and clear indication of location in website
  • Provide visible controls for audio and video players
  • Ensure form elements include clearly associated labels, with space for important instructions
  • Present form errors in a block above the form and make the fields in error extremely visually salient
  • Structure text to include headers, not be too wide, and in a good font size
  • Learn more about accessibility

Feedback

This document was raised for general feedback in the 10 April Survey and discussed on 17 Apr meeting.

General questions

  • Where will this be housed? How would someone access the resource? {Melody, 15 Apr 2015}
    • Much like the tutorials this will have a home within the WAI resources and (ideally) will be linked to from WAI core navigation. {Kevin, 16 Apr 2015}
  • Readers need to be aware that these are just high-level tips and there's a lot more techniques that are not included here. {Melody, 15 Apr 2015}
    • The intention of the last item on the list regarding learning more is to clarify this point. {Kevin, 16 Apr 2015}
  • I assume these are to be like "Easy Checks." Is that correct? {Anna Belle, 15 Apr 2015}
    • Similar, but less in-depth. Short and sweet is the goal. {Kevin, 16 Apr 2015}
  • Objectives: Remove #1. {Sharron, 15 Apr 2015}
    • Wording aside, I think there is a need to include this as an objective for those non-technical, new, or summary seekers. The aim of the objective is to highlight this approach {Kevin, 22 Apr 2015}
  • Suggested Audiences: add trainers, add advocates, add consultants {Sharron, 15 Apr 2015}
    • Included an additional objective to cover these additional audiences. They are not necessarily target readers which is why I haven't included them as main audiences {Kevin, 22 Apr 2015}
  • For Suggested Audiences, I would add "Project Manager" in addition to "Manager" since in my world those are quite different roles {Anna Belle, 15 Apr 2015}
    • 'Manager' was included to mean 'Project manager'. I was hoping to keep the titles similarly snappy. However, you are right that there is too much ambiguity with 'Manager' on it's own. {Kevin, 22 Apr 2015}

Discussion topics

  • The example doesn't include an illustration. {Anna Belle, 15 Apr 2015}