Re: [Improving the Accessibility of Your Website]

Hi Joy,

Thank you for your valuable comments on this document!

You say: "I note areas where there is no space between the period and 
the beginning of the next sentence."

Could you please provide one or two examples of this? I suspect this may 
be due to the coding of some of the lists rather than punctuation.

Many thanks,
   Shadi


On 6.4.2016 23:45, Joy Relton wrote:
> Below are a few comments. Over all this is an excellent document.
>
> Title: Improving the Accessibility of Your Website
>
> Under
>
> Improving the Accessibility of your website
>
> Define the Scope
>
> • Key content, such as frequently accessed content and content that is particularly relevant to people with disabilities. This includes content that has
>
> been highlighted through user feedback mechanisms.
>
> jR----add an example..” (many managers will not have any idea what you are talking about) I don’t”
>
> )”
>
> Under “implement repairs, the tips phrase
>
> The majority of repairs often falls to developers to address, but some issues, such as content or issues with process,
>
> will be better handled by others.
>
> should read ----
>
> JR
>
> The majority of repairs often fall to developers to address, but some issues, such as content or issues with process, will be better handled by others.”
>
> JR—This is an excellent document please run spell check and grammar check before posting it as a final copy. I note areas where there is no space between the period and the beginning of the next sentence. Also, by checking “check grammar on the spell checker setup of your word processor you will catch grammatical errors.
>
>
>
>
>
> end
>
>
>
> W3C logo
>
> Web Accessibility initiative
>
>
>
> WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities
>
> banner end
>
>
>
> navigation region
>
> Site navigation
>
>
>
> W3C Home
>
>
>
> Web Accessibility Initiative (WAI) Home
>
>
>
> list of 7 items
>
> Getting Started
>
> Designing for Inclusion
>
> Guidelines & Techniques
>
> Planning & Implementing
>
> list of 2 items nesting level 1
>
> Policy Resources
>
> list of 3 items nesting level 2
>
> ◾
>
> Standards Harmonization
>
> ◾
>
> International Policies
>
> ◾
>
> Organizational Policies
>
> list end nesting level 2
>
> Managing Accessibility
>
> list of 4 items nesting level 2
>
> ◾
>
> Strategic Planning
>
> ◾ »Improving Existing Sites
>
> ◾
>
> Involving Users in Web Projects
>
> ◾
>
> Selecting Authoring Tools
>
> list end nesting level 2
>
> list end nesting level 1
>
> Evaluating Accessibility
>
> Presentations & Tutorials
>
> Getting Involved with WAI
>
> list end
>
>
>
> Discover new resources for people with disabilities, policy makers, managers, and you!
>
>
>
> characters from different languages  Translations
>
> navigation region end
>
>
>
> main region
>
> -
>
>
>
> Status: This is an in-progress, unapproved draft.
>
>
>
> Improving the Accessibility of Your Website
>
> Page contents
>
> list of 7 items
>
> Understand the issue
>
> Define the scope
>
> Define your target
>
> Perform detailed review
>
> Prioritize repairs
>
> Implement repairs
>
> Longer term: Strategic planning
>
> list end
>
>
>
> Introduction
>
>
>
> Websites are made accessible to people with disabilities most efficiently and effectively when accessibility is considered early and throughout a project
>
> and organization.
>
>
>
> If you need to fix accessibility barriers on an existing website now, this document is for you. Guidance for addressing accessibility as a long-term program
>
> is available in
>
> Planning and Managing Web Accessibility.
>
>
>
> Understand the issue
>
>
>
> Accessibility barriers are frequently introduced due to lack of awareness by designers, developers, content authors, and others involved in the website
>
> creation and maintenance process. Ensuring that everyone involved in the process has at least basic understanding of web accessibility will greatly support
>
> your improvement plan. Some of the resources to consider for introducing web accessibility include:
>
>
>
> list of 5 items
>
> • W3C - Accessibility
>
> — Briefly introduces web accessibility and links to additional resources.
>
> • Accessibility Principles
>
> — Introduces web accessibility requirements and provides links to Web Content Accessibility Guidelines (
>
> WCAG).
>
> • How People with Disabilities Use the Web
>
> — Explores the impact of accessible design with real-life examples.
>
> • Tips for Getting Started
>
> — Provides some basic considerations for making websites accessible and links to additional guidance.
>
> • Easy Checks — A First Review of Web Accessibility
>
> — Simple steps to help you determine whether or not accessibility is addressed in even the most basic way.
>
> list end
>
>
>
> back to page contents
>
>
>
> Define the scope
>
>
>
> Depending on your situation you may not be able to address all the issues on every part of your website at once. You may need to prioritize specific areas
>
> of your website to improve right away, and address the remaining parts in later stages. Some of the aspects to help you prioritize and define your initial
>
> scope include:
>
>
>
> list of 3 items
>
> • Key user journeys, such as registration, purchase, or checkout processes offered by the website. This needs to include the entire journey, as barriers
>
> on any part impact the journey.
>
> • Key content, such as frequently accessed content and content that is particularly relevant to people with disabilities. This includes content that has
>
> been highlighted through user feedback mechanisms.
>
> • In-development content, such as areas of the website that are currently being redesigned or that are scheduled for redesign.
>
> list end
>
>
>
> Be sure to consider the website in its entirety. This includes any mobile apps and third-party content that provide functionality to the website. For example,
>
> the banking application is a key part of an online bank, also when it is provided as a mobile application. Also third-party content, such as online payment
>
> and ticketing systems, as well as social media platforms used to engage with your audience could be considered key functionality of your website.
>
>
>
> back to page contents
>
>
>
> Define your target
>
>
>
> The generally accepted target for accessibility is Level AA of the Web Content Accessibility Guidelines (WCAG) 2.0. This may already be the standard specified
>
> in your organizational policy or it may be a legal requirement for your website.
>
>
>
> In some situations, you may need to define a multi-tiered target with different dates for different levels. For example, meet WCAG 2.0 Level A success
>
> criteria in the coming release, and meet Level AA success criteria in all pages within 12 months.
>
>
>
> Related resources
>
> list of 2 items
>
> • Web Content Accessibility Guidelines (WCAG) 2.0
>
> — Explains how to make web content more accessible to people with disabilities.
>
> • wai-planning-and-implementation/pol
>
>   — Describes considerations when making simple or comprehensive policies for organizations
>
> list end
>
>
>
> back to page contents
>
>
>
> Perform detailed review
>
>
>
> Perform thorough evaluation of the content defined in scope, to the defined accessibility targets. In many cases it is beneficial to evaluate more broadly
>
> than the defined target. There are likely some higher level criteria that you already meet or are easily achieved.
>
>
>
> Thoroughly evaluating shared elements can help obtain more information with less effort. For example, templates, style sheets, and any consistent items
>
> that are repeated, such as navigation bars and footers, should only need to be evaluated once.
>
>
>
> Tips
>
> list of 4 items
>
> • Before assessing, fix any known barriers.You may already know of accessibility barriers, for example from cursory checks using
>
> Easy Checks.
>
> If possible, repair these before going further. This can bring early site improvement. More importantly, if you are involving users in your evaluation,
>
> any existing barriers may make it difficult for them to review the complete website.
>
>
>
> • Evaluate using a standardized approach.Ensure that you are consistent in applying your evaluation methodology. This allows you to repeat the evaluation
>
> and compare the results.
>
> WCAG-EM
>
> is a comprehensive and structured approach to help determine how well a website conforms to WCAG.
>
>
>
> • Use appropriate evaluation and repair tools.Web accessibility evaluation tools will help check if a website meets accessibility guidelines. There are
>
> also tools that help repair accessibility barriers. Some evaluation tools can be configured to the specifics of your project, such as conformance level
>
> or pages to be evaluated. This can speed up the evaluation and simplify any reports.
>
>
>
> • Evaluate with real users.If possible, evaluate with users to help your team understand the real-world impact of accessibility issues. An understanding
>
> of the effect of accessibility barriers helps in creating better solutions. Observing sessions where users wrestle with your site can also be a powerful
>
> motivator for your project team.
>
> list end
>
>
>
> Related resources
>
> list of 4 items
>
> • Website Accessibility Conformance Evaluation Methodology
>
> — An approach for determining how well a website conforms to WCAG.
>
> • Involving Users in Evaluating Web Accessibility
>
> — Guidance on including people with disabilities in accessibility evaluation throughout Web development.
>
> • Selecting Web Accessibility Evaluation Tools
>
> — Guidance on choosing which Web accessibility evaluation tools to use to help evaluate Web accessibility.
>
> • Web Accessibility Evaluation Tools List
>
> — List of software or online services that help in performing accessibility evaluations.
>
> list end
>
>
>
> back to page contents
>
>
>
> Prioritize repairs
>
>
>
> When faced with limited resources or a need to respond quickly to issues, you will need to prioritize your repairs. Two factors to consider are:
>
>
>
> list of 2 items
>
> • What is the impact on people with disabilities?Accessibility barriers are often identified by WCAG success criteria. Each success criteria has a Level
>
> (A, AA, AAA) that helps determine the impact of the barrier. The actual impact depends on the context of the barrier. For example, issues in templates
>
> that are shared between many pages, will have a broad impact and issues in key pages, such as the home page or shopping cart checkout, may have a specific
>
> but significant impact. Involving users with disabilities and accessibility specialists can help in determining how significant each barrier is.
>
>
>
> • What is the effort required for repair?The time, cost, and skills required to fix an issue will vary greatly. For example, repairing an issue in the
>
> header could require a simple change to a template that is propagated throughout the website, or it could require changing every page manually. Repairing
>
> missing alternative text requires understanding how the image is used and writing skills; whereas, changing a site to effectively use style sheets requires
>
> CSS skills.
>
>
>
> Discussion with everyone involved can help you quickly determine possible solutions, what effort would be required to implement them, and who has the required
>
> skills. Ensure that whoever is responsible for implementing the solution is involved, as they will be able to highlight any additional constraints.
>
> list end
>
>
>
> Tips
>
> list of 2 items
>
> • Prioritize high impact, easily addressed barriers.This provides the most improvement in the shortest time. Creating a graph of impact versus effort can
>
> help you quickly determine high priority barriers. This approach usually takes less time. However, it may result in harder-to-fix or low impact issues
>
> always falling out of scope.
>
>
>
> • Prioritize important functionality or high use content.It is usually best to first repair those areas that have the greatest impact on user experience.
>
> Identify key pages or journeys within the website and fix problems in those areas. For example, the home page may be a primary entry point, or purchasing
>
> a product and payment process may be important functions. Frequently-used, high-traffic pages and functionality can be identified using analytics.
>
> list end
>
>
>
> Related resources
>
> list of 1 items
>
> • How People with Disabilities Use the Web
>
> — Provides examples of how people with disabilities use the web, which can be helpful when prioritizing issues.
>
> list end
>
>
>
> back to page contents
>
>
>
> Implement repairs
>
>
>
> Once issues are prioritized, you will be better able to plan how long it will take to fix them based on the estimated effort. This gives a clear indication
>
> of what is achievable given the project resources available.
>
>
>
> Tips
>
> list of 4 items
>
> • Distribute tasks throughout your team.The majority of repairs often falls to developers to address, but some issues, such as content or issues with process,
>
> will be better handled by others. For example, if text in primary content is not linked clearly then whoever manages your content can address this. For
>
> each issue to be fixed, ensure that it is clear who does the work and that they have the appropriate skills or knowledge.
>
>
>
> • Communicate requirements to those responsible for delivery.Ensure that those who have been given responsibility for each task are aware of the specific
>
> requirements they need to meet. This may be a subset of the target standards for your organization. Encourage implementors to understand the requirement
>
> and why it is important so that solutions best address the issue.
>
>
>
> • Validate solutions as early as possible.Sometimes there is no perfect solution or a solution might introduce other problems. Evaluate the repairs to
>
> ensure that the issue has been adequately addressed. If possible, seek to validate the solution at the earlierst opportunity to avoid the cost of implementing
>
> something that may not adequately address the issue.
>
>
>
> • Engage external experience and knowledge.It is often best to combine educating existing staff with bringing in outside expertise, either hiring additional
>
> staff or engaging consultants. An accessibility specialist can save time and effort in the long run by providing:
>
>
>
> list of 2 items nesting level 1
>
> ◦ The latest best practices for accessibility solutions.
>
> ◦ First-hand experience of how people with disabilities interact with the Web.
>
> list end nesting level 1
>
> list end
>
>
>
> Related resources
>
> list of 1 items
>
> • How People with Disabilities Use the Web
>
> — Provides examples of how people with disabilities use the web, which can be helpful when prioritizing issues.
>
> list end
>
>
>
> back to page contents
>
>
>
> Longer term: Strategic planning
>
>
>
> Thinking about accessibility tactically will generally be less cost effective and efficient than considering it as an integral part of your web development
>
> strategy. There are several things you can do to help your organization create more accessible websites as standard.
>
>
>
> Tips
>
> list of 2 items
>
> • Consider accessibility as an organizational strategic goal.Ensure that when redesigns or updates are planned, accessibility is included from the start
>
> of the project. Accessibility is much less costly and time-consuming when tackled at the beginning of a project, rather than the end.
>
>
>
> • Develop an organizational policy on accessibility.If not already available, an organizational policy on web accessibility will define your goals for
>
> how your organization will support the creation of accessible web content and services.
>
> list end
>
>
>
> Related resources
>
> list of 2 items
>
> • Planning and Managing Web Accessibility
>
> — Provides guidance on activities important to long-term accessibility planning in your organization or project.
>
> • Developing Organizational Policies on Web Accessibility
>
> — Describes considerations when making simple or comprehensive policies for organizations.
>
> list end
>
>
>
> back to page contents
>
>
>
> complementary information
>
> Help improve this page
>
>
>
> Please share your ideas, suggestions, or comments via email to the publicly-archived list
>
> wai-eo-editors@w3.org
>
> or via GitHub.
>
>
>
> E-mail
>
> Fork & edit on GitHub
>
> New GitHub Issue
>
> complementary information end
>
> main region end
>
> content information
>
> Document information
>
>
>
> Status: Draft approved by
>
> EOWG
>
> updated October 2014 (first published: March 2006)
>
> Editors:
>
> Kevin White,
>
> Shawn Lawton Henry
>
> and
>
> Shadi Abou-Zahra.
>
> Contributors: Sharron Rush, Anna Belle Leiserson, and
>
> participants
>
> of the
>
> Education and Outreach Working Group.
>
> Updated with support from
>
> WAI-ACT
>
> and developed with support from
>
> WAI-TIES,
>
> both projects of the European Commission IST Programme.
>
>
>
> [WAI Site Map]
>
> [
>
> Help with WAI Website]
>
> [
>
> Search]
>
> [
>
> Contacting WAI]
>
> Feedback welcome to
>
> wai-eo-editors@w3.org
>
> (a publicly archived list) or
>
> wai@w3.org
>
> (a WAI staff-only list).
>
>
>
> Copyright © 2014 W3C ®
>
> (MIT,
>
> ERCIM,
>
> Keio,
>
> Beihang)
>
> Usage policies apply.
>
> content information end
>
>
>
> Joy Relton
>
> Accessibility Consultant
>
> Deque Systems, Inc.
>
> 703-225-0380 Ex. 103
>
> 2121 Cooperative Way Suite 210
>
> http://www.deque.com
>
>
>
>

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/
Activity Lead, WAI International Program Office
W3C Web Accessibility Initiative (WAI)

Received on Thursday, 14 April 2016 13:09:35 UTC