Feedback: Improving the Accessibility of Your Website

For review: Improving the Accessibility of Your Website

Please provide your comments inline below.

Comment template:

• summary — comment {name, date}

General feedback

• info here versus Implementing doc - I haven't read it all in detail yet, but have a general impression that there is a lot content (especially under Implement Repairs, Review and Plan to Revisit, Next steps: Strategic Planning sections) that is already in (or should be in) the newly-updated main Implementing document. Can we look at making this doc just focused and specific, and clearly point to the other doc for broader info? {Shawn, 2 Oct 2014}

• Relationship between Improving & Implementing. is the right stuff in the right place? maybe move some info from Improving to Implementing? (e.g., details on Tools) Wayne's comment http://lists.w3.org/Archives/Public/w3c-wai-eo/2014OctDec/0002.html {from EOWG telecon 3 Oct}

• Clearer organization of info, esp for Determine Scope & Target and Evaluate (Assess the Situation). (e.g., "Fix any known barriers." seems out of place. and mention of Levels missing early) {from EOWG telecon 3 Oct}

• [Done, Kevin, 9 Oct]: Evaluate: Easy Checks early? WCAG-EM too much? nothing in between, though... {from EOWG telecon 3 Oct}
  • If the focus of this document is on organizations that are new to accessibility with little framework then WCAG-EM should be a good resource for them. WCAG-EM handholds them through how to do an evaluation.

• [Done, Kevin, 9 Oct]: Examples distracting or helpful? (e.g., ... for example poor color contrast ... For example, while addressing color contrast in the CSS you might also fix keyboard focus styling of links in the same CSS.) {from EOWG telecon 3 Oct}

• [Done, Kevin, 9 Oct]: Review and Plan to Revisit - Review is an important part of the process and can stand alone. When you add "Plan to Revisit" it makes the section sound oddly anticlimactic and less action-oriented than the rest of the document. "Plan to Revisit" to me invokes the term "continuous improvement" used by "lean" organizations. Integrating accessibility into day-to-day operations should be reinforced, and this is specifically called out in "Next Steps: Strategic Planing." Maybe remove "Plan to Revisit" from the header and put the idea into the following section, "Next steps: Strategic Planning?" {Paul, 3 Oct 2014}
  • I have re-framed the last stage to be 'Review Achievements'. This seemed to give a stronger end to the process. There is still a 'Set a follow-up date' but with less emphasis as no longer in the title. I didn't put anything additional in the final section as it didn't quite fit with the 'go read this' general message of that section.

• [Done, Kevin, 9 Oct]: I feel as though a lot of the document is trying to figure out what the motives that an entity might have in order to do this stuff. There are many plausible reasons, but the purpose should be to help an entity improve the accessibility no matter what, regardless of their ulterior motives. {Jonathan, 3 Oct 2014}
  • I think this may be a symptom of the lack of clear identity. I have changed the tone of the introduction to be more pointing to the idea that even if you don't have the internal framework, there is still stuff you can do. I have also removed the 'who is this for' as that seemed to exacerbate the identity confusion.

• [Done, Kevin, 9 Oct]: I really feel like we should change 'Website' to 'Web Content'. A lot of people tend to separate the two as particular concepts, and it limits progress because of it. {Jonathan, 3 Oct 2014}
  • I have used this phrase in a number of places to improve the flow. I don't know how much more I want to go into this as I think the do so would require some clear definitions of terms that may be more suited to a guidelines or specification document.

Intro

• Approach in first sentence is abrupt and in some ways presumptuous. We don't know that people who are reading this are from orgs that "lack the policies, processes, or skills required to support accessible websites." It may be that they are here to do a process check against what the W3C presents as typical. It may be they are trying to standardize. In any case, this approach does not frame the content as something useful to put out an accessibility fire, which is what I thought we were aiming for in this particular document.
  • Suggested alternative: Web accessibility is achieved and maintained as the result of deliberate design and process choices and full integration into the development software lifecycle. For guidance on how to most effectively succeed in that long term goal, you will want to study WAI's Implementing Web Accessibility. In the meantime however, you may have an organizational need to identify and remove immediate barriers to a web site or application. This document is meant to help you do that. {Sharron, 9 Oct 2014}
• Info from prior document — I think some of the intro in the current document is useful and seems missing from the edit. {Shawn, 2 Oct 2014}
  • Shawn, could you elaborate on what in particular you feel is missing? {Kevin, 9 Oct 2014}

• [Done, Kevin, 9 Oct]: intro general — I find it a bit too wordy with unnecessary information, such as: "The barriers may be as a result of little or no consideration for accessibility when the website was created or may have slowly developed as new content was added." and "It is likely that you will be relatively new to accessibility or new to managing accessibility projects." and "This document presents the information as topics that you will need to consider. Information from prior topics is often required for subsequent activities so you may need to consider how you plan to approach them." {Shawn, 2 Oct 2014}

• [Done, Kevin, 9 Oct]: resources listing first item - "The place to start for a short introduction to Web accessibility." prefer the original text: "Briefly introduces web accessibility and links to additional resources." {Shawn, 2 Oct 2014}

• [Done, Kevin, 9 Oct]: resources listing items - 1. Maybe not link to Essential Components 'cause it's long and a little tangential, AND it's linked from the first doc (W3C - Accessibility). 2. I think *not* link to Business Case here. Probably most people who are using this page are already committed to doing it, AND it's linked from the first doc (W3C - Accessibility), and the main Implementing page. {Shawn, 2 Oct 2014}

• [Done, Kevin, 9 Oct]: resources listing - How PWDs - this draft has "Examples of people with different disabilities using websites, applications, browsers, and authoring tools." I think the text in the current document is more descriptive and informative: "describes how different disabilities affect web use and accessibility requirements for people with different kinds of disabilities, and includes scenarios of people with disabilities using the Web." -- although it could be shortened. Also, I think we should especially call out the Accessibility Principles page, e.g., something like "The Accessibility Principles page provides a succinct introduction to web accessibility requirements and links to standards to meet the requirements." {Shawn, 2 Oct 2014}

What is this document for

• [Done, Kevin, 10 Oct]: As is, it is too tentative and irresolute. "you *may* find it difficult..." and the document "*may* be useful..." etc. WAI/W3C is where people look for answers, let's be more definitive.
  • Suggested alternative: This material provides steps and techniques for site owners and managers to consider when faced with the need to quickly improve the accessibility of a web property. This approach will help you make short term improvements, but it's important not to lose sight of the need for the development of internal policies and processes in order to sustain accessibility over the longer term. {Sharron, 9 Oct 2014}

Using this Document

• [Done, Kevin, 10 Oct]: Redundant redundancy: There are some key steps you will need to plan for. Each step is described and includes important points for you to consider.
  • Suggested alternative: Key steps to an accessibility improvement plan are outlined here and link to further description. {Sharron, 9 Oct 2014}

Determine Scope and Target

• [Done, Kevin, 10 Oct]: First paragraph, third sentence.
  

Current: "Target is the accessibility standard you aim to evaluate against and conform to."
Suggested change: "Your target is the accessibility standard you aim to evaluate against and conform to."
Rationale: Just easier to read. At first, I simply stumbled over and re-read wondering if something was missing.
Suggested by [9 Oct]:

• [Resolved, Kevin, 10 Oct]: Third paragraph.
  

Suggestion: Would it be a good idea to provide an example and highlight it in red?
Current: Your scope may be confined to a specific barrier. Even with restricted scope you might take the opportunity to fix other issues in related areas of the website.
Suggested change: Your scope may be confined to a specific barrier. For example, an online registration form. Even with restricted scope you might take the opportunity to fix other issues in related areas of the website.
Suggested by [9 Oct]:

• • I think this may result in too many examples in this section. There is already the mention of issues in CSS. Replacing or changing the example may result in much more detailed description that may be inappropriate.

• [Done, Kevin, 9 Oct]: missing conformance level - under "Set a standard and conformance level." it doesn't say anything about conformance level (e.g., A, AA, AAA) {Shawn, 3 Oct 2014}

Assess the Situation

• This paragraph is not needed, (it is important but not relevant in this context, imo). Suggest removing since it blurs the line between long-term and short-term approach:

Knowing the cause of issues can help in your planning. For example, if only a few data tables are missing necessary markup, then you might include adding table markup to quality assurance processes. However, if none of the tables are properly marked up, you would consider additional training on data table markup. If tables from one development team are done properly, but another teams are not, this helps clarify where training is needed. {Sharron, 9 Oct 2014}

• [Done, Kevin, 10 Oct]: (Last sentence, first paragraph)Comment: I find the following sentence puzzling. Can we do without it?
  

More importantly, if you are involving users in your evaluation, known existing barriers may make it difficult to obtain feedback on other areas.
Suggested by [9 Oct]:

• • Rather than remove, I have reworded. It is useful to note that known barriers may impact on the ability of users testing the site and limit what can be discovered.

• [Responded to, Kevin, 10 Oct]: Evaluate with real users
  

Current: In addition to helping identify and prioritize accessibility barriers, watching people struggle to use your site can be a powerful motivator for your project team.
Suggested change: In addition to helping identify and prioritize accessibility barriers, evaluating with real users can be a powerful motivation for your project team as they learn at first hand the range of difficulties people encounter in using your site.
Suggested by [9 Oct]:

• • I aimed here to highlight that 'wince factor' that is seen when developers and designers watch users try in vain to use the finely crafted site. I tried to make this succinct and punchy to highlight this.

• [Responded to, Kevin, 10 Oct]: Consider how authoring tools might introduce barriers.
  

Current: (Third bullet point) Upgrading your existing tools to the latest version, if they have better accessibility support.
Comment: Isn't that a given, i.e., wouldn't that be normal/standard to upgrade?
Suggested by [9 Oct]:

• • Not necessarily. Software upgrades are often held back for a variety of reasons. If this is the reason then accessibility needs might move an upgrade forward.

• [Done, Kevin, 10 Oct]: Last paragraph:
  

Current: For some content, such as video or PDF, there may be an involved creation process with a number of tools involved.
Comment: "involved" is used twice. Is it possible to omit the second occurrence of "involved"?
Suggested by [9 Oct]:

Prioritize Solutions

What is the impact on people with disabilities?

• [Done, Kevin, 10 Oct]: Suggested rewrite: While WCAG Success Criteria are the best measure of overall accessibility barriers, human experience and judgement is critical when addressing immediate issues. Designation of WCAG Level A, AA, or AAA often indicates the generalized impact of a particular accessibility barrier. The actual impact depends on the context of the barrier and the target audience. For example, poor contrast in the main content has a high impact, whereas in generic footers it will be lower. User experience testing and reporting is therefore an important metric of accessibility barriers. {Sharron, 9 Oct 2014}

• [Resolved, Kevin, 10 Oct]: Last sentence: Evaluating with users will also help determine the impact of accessibility any barriers. Comment: Either a word is missing or "any" should be removed.[Oct 9]
  • Changes to the previous paragraph made this sentence redundant, so it has been removed.

Implementing Repairs

• [Done, Kevin, 10 Oct]: Second paragraph, first sentence: The brunt of repairs often fall to developers to address but some issues, such as content or issues with process, will be better handled by others.

Suggested change: The brunt of repairs often falls upon developers....[Oct 9]

• [Done, Kevin, 10 Oct]: Second paragraph, second sentence: For example, where link text in primary content is unclear, whoever manages your content can address this.
  

Suggested change: For example, where text in primary content is not linked clearly, whoever manages your content can address this.
Rationale: At a first reading, I understood that the unclear text might be related to color contrast so I immediately thought of colors in the style sheet. Perhaps, it's a just reflex I had. Curious if anyone else had that thought and, therefore, my suggested change. [Oct 9]

Strategic Planning

• [Done, Kevin, 10 Oct]: First sentence: Thinking about accessibility tactically will generally be less cost effective and efficient that considering it as an integral part of your web development strategy. Typo: change "that" to "than" [Oct 9]

• [Done, Kevin, 10 Oct]: Second bullet point: Ensure that you have an effective accessibility policy in place that specifies that your website meet or exceed legal requirements.
  

Suggested change: leave out "exceed" and add an "s" to "meet." It then becomes: Ensure that you have an effective accessibility policy in place that specifies that your website meets legal requirements. [Oct 9]