Re: reply requested, wrapping up Involving Users doc

Sailesh,

Thank you for you review and comments. Your comments are surrounded by <blockquote> and my replies are preceded with SLH: below

<blockquote>
Upon re-reading the doc, I came up with the following  for you to consider:
1. Ref: For example, take a Web developer who does not know what it is like
to use a screen reader.
Comment: Consider rewording as-
Consider a developer who is unaware that there are individuals who listen to
and interact with Web page content using screen-reading software, or  a
developer who does not know how content  creation and coding  affects the
output of such screen-reading    software.
</blockquote>

SLH: We want to keep the document as short and succinct as feasible. The target audience for this particular document is mostly people who are already somewhat involved in Web accessibility, rather than newbies. Therefore, I propose that we keep this bit as short and simple as possible.

<blockquote>
2. Ref: When Web developers, managers, and other project stakeholders see
people with
disabilities use their Web site, most are highly motivated by a new
understanding of accessibility issues.
Comment:  Instead of "motivated" consider :
suddenly realize or become aware how differently their Web pages are
rendered for
individuals  with disabilities or by assistive technologies.

I think when I demo  Web surfing with    a screen reader or show a Web page
with colors
turned off, etc., it is a more of an eye-opener for the audience. I will not
agree everyone
or most are "motivated" after the demo. Many question the  statistics of
PWD,  the business
benefits or the extra efforts needed or the learning they need to do.
</blockquote>

SLH: I agree that demoing Web surfing with a screen reader is more of an eye-opener and that leads to more questions. This talks about project member actually seeing people with disabilities *use* *their* site. In every such case I've observed, people are highly motivated, and others in EOWG report the same thing. The "most" covers that some might not. Also, if the project team is observing PWDs using their site, they have probably already started addressing many of the questions you list. The goal of this section is to show the power of including PWDs, and I think the "motivated" helps do that.

<blockquote>
3. I think the document needs to highlight that  the developers get a
realistic feel of how content is rendered to PWD and how the AT devices most
likely being used in the target-population render the content. Yes,
developers should code as per "accessibility techniques and guidelines" but
if certain techniques are better supported     than others, they should use
those techniques. 
</blockquote>

SLH: hum, I wonder if this is implicitly covered enough in the introduction? I'll list this for EOWG discussion tomorrow.

<blockquote>
Yes,
developers should code as per "accessibility techniques and guidelines" but
if certain techniques are better supported     than others, they should use
those techniques. 
</blockquote>

SLH: Agree with your point (although that's not a specific focus of this document).

<blockquote>
Developers need to be aware that the content accessed by a
PWD using AT depends on the interoperability of the At devices in addition
to  that of coding practices and the browser.
</blockquote>

SLH: We cover that a bit in the Analyzing Accessibility Problems section: "Web accessibility depends on several components of Web development and interaction working together, including Web browsers, assistive technologies, and Web content. For any accessibility problems you identify, determine which components are responsible. For example...", which links to the Essential Components doc (http://www.w3.org/WAI/intro/components.php).

OK?

Regards,
~ Shawn

Received on Thursday, 13 October 2005 22:56:37 UTC