Training Materials Part II -- Topics for Web Accessibility Presentations and Training

EOWG Editors:

Here are comments for the "Accessibility Topics" page.

Jennifer

2. Topics for Web Accessibility Presentations and Training 
http://www.w3.org/WAI/training/topics.html
- [Editor's draft in progress - updated 11 August 2010]

2.1.  the page title says "Presentation Topics. . . ," but the link 
on the previous page was "Accessibility Topics."  Maybe they should 
be consistent, or maybe shorthand is ok.

2.1.1.  Also, the page title and the h1 are not the same on this page.

2.2. "This page provides material for web accessibility topics that 
you can use as building blocks to create presentations and training sessions."

JS:  As a newcomer, I'm not sure I'd know what to expect.  What about:

"This page provides material to help you present web accessibility 
topics. Use this material to create presentations and training 
sessions. Adapt and combine these examples to your audience and goals."

JS: While I'm not cutting enough, I'm thinking it might be good to 
try to convey action and how you get there quickly. I'm envisioning 
that people may be in a hurry to start building their presentations 
because I suspect many may come to these pages at the last minute.

2.3. [h3] "Resources for developing a presentation on this topic"

JS: Maybe delete "on this topic," since it should be clear.  Might be 
good to remove the phrase consistently.

2.4. Might take a look at the parenthesis; I think there's something 
slightly odd:

[link] Before and After Demonstration
  )

2.5. [h3] "Tips and suggestions for speakers"

JS:  I wonder if this heading can be consistently shortened.

Just "Tips and Suggestions?"

or "Suggestions?"

Perhaps it's clear that all this is directed toward speakers.

If I suggested more words in a previous set of comments, then I 
respectfully request to change my mind.

2.6. "Use various assistive technologies and adaptive strategies, OR
  some images of assistive technology users, to illustrate the range 
of access methods
[JS: delete: used by people with disabilities]

2.7.  "Is it enough to make just one of accessible?"

JS:  I am not sure what is meant.

2.8. Maybe change the and symbol to the word since it's a little 
confusing if I don't have punctuation turned on:
WCAG logos
  &
ATAG logos
  - how and when to use the conformance logos

2.9.  It might be helpful to read all goals. Most start with action 
verbs, as I think they should, but not all do. For example, I see a 
couple that start with "Encouraging," but I think Encourage could work.

2.10. Might review Audience sections.  I'm not sure punctuation is 
consistent. In many, I see semicolons but in another, I see commas. 
If commas are chosen, for example, in here, the and is missing at the 
end in Topic 3:

Audience:
  Web developers and others with professional responsibility for 
creating accessible
online content and applications; accessibility advocates; ICT departments

JS: I think I would have voted for commas, throughout the listing of 
the audiences, but it's likely a matter of personal style.

2.11.  Maybe this could be a little clearer.

"This topic presents the use of WCAG 2.0 when developing websites 
(especially techniques
to use, and 'failure' techniques to avoid) that will be accessible to 
people with
disabilities and older people."

JS proposal: "This topic presents the use of WCAG 2.0 when developing 
websites (especially techniques to use, and techniques to avoid) that 
will improve accessibility for people with
disabilities and older people."

2.12. I am not sure "to draw from" is necessary.  People might use 
the presentation wholesale.

2.13. Learn how to choose the most accessible options for in-house 
CMS and other authoring tools

JS:  "Learn how to choose the most accessible options for an in-house 
Content Management System and other authoring
tools"

2.14. "Ask if anyone has experienced problems browsing the Web with a 
mobile phone[JS: change ? to a period]"

2.14.1.  "[JS: del Briefly
[D]iscuss how these [Js:  I'm not sure to what "these" is referring.] 
might be similar to the barriers faced by people with disabilities,
but many of the solutions benefit both groups.


2.15. "It also covers how to maintain [JS: it -- what; is this the 
Web site or the process?] over time, once accessibility is achieved.

2.16. "It demonstrates [JS: del of] how users can
identify usability aspects of accessibility that are not always 
discovered by conformance
evaluation alone.

2.17. "describes the benefits [JS: from and change to of] evaluating 
with real people and identifying usability"

2.18." Ask participants to identify opportunities to involve users in 
their own project
[JS: del and discuss]"

JS: Maybe change "their own project" to "a project"

2.19. Is this why the lit review was created internally, rather than 
how this group might use it?

"the Literature Review is to inform education and outreach to better 
promote accessibility
solutions for older Web users"

I'm not sure whether "education and outreach" might sond a little like jargon.

2.20. Does the word "page" need to be in some of these links:

[link] WAI-AGE Project page

[link] WAI-AGE Project Deliverables page

2.21.  Maybe MWBP need only be written out once, and the abbreviation 
shown, and then it could be abbreviated thereafter.

2.21.1.  I'm not sure what the style should be for abbreviations i.e. 
I'm not sure I have seen ATAG and UAG written out once and 
abbreviated thereafter.

2.22.  Should it be "describe?"
"describes what also needs to be done to meet WCAG for those familiar 
with MWBP"

2.23.  Is it important to always cite WCAG 1.0 in places other than 
the migration discussion?  Can we focus on WCAG 2 as much as 
possible?  I am afraid for this audience, while it may be technically 
correct to keep WCAG 1.0 in mind, it may be overwhelming in some 
cases as these people seek to prepare and simplify their presentations.

I'm not suggesting that we should not be technically accurate.

2.24. I'm not sure this resource is consistently referred to; I'm not 
sure I've seen "quicktips," before this reference:
[link] Web Accessibility QuickTips - WCAG 2 at a Glance

Actually, there's at least one other reference; maybe it should be consistent.

2.25. including benefits,
techniques [JS: add comma] and limitations.

2.26. "Evaluation tools and their limitations: assistive 
technologies, accessibility test tools, [JS: add and] developer tools"

2.27. "describes the benefits [JS: change from to of] evaluating with 
real people and identifying usability"


2.28. "change for illustrating to to illustrate -- sounds more 
active.  Also check for this phrase in other places if you agree] 
browser-based evaluation techniques and automated tools

2.29. "while [JS: many] tools are still oriented towards WCAG 1.0 
evaluation, they can give a useful overview)"

JS:  Have things been evolving enough this year that we could say 
"some," instead?  It'd sound more positive and progressive.

2.30. "Benefits of involving users [change for a comprehensive 
evaluation to to obtain a more comprehensive evaluation"

But I'm not sure I like "obtain".

2.31. Maybe look for another word for "comprehensive since it's used 
in two points in a row.
Maybe:

"Reporting findings completely and understandably"

Received on Tuesday, 17 August 2010 19:42:09 UTC