Re: w3.beta Comments for discussion

Hi Shawn,

Shawn Henry wrote:

>> "When the web meets its full potential, it is accessible to everyone, 
>> including people with a diverse range of hearing, movement, sight, and 
>> cognitive ability. The flexibility of the web enables most people with 
>> impairments to use the web just as well as anyone. Think about what 
>> this means: There is inherently no such thing as a disability using 
>> the web. ...However: When websites and web tools are not accessible, 
>> they exclude people from using the web.
>> [or:..., they disable people from using the web.]"
>>
>>
>> Suggest:
>>
>> "The web should be accessible to everyone, including people with 
>> different levels of vision or hearing, different ranges of movement, 
>> different levels of literacy or cognitive function, different 
>> software, hardware or internet connection speeds.
> 
> SLH: We have decide to keep "accessibility" limited to related to 
> disability. While I'm OK with having the first sentence broader (since 
> it doesn't include "accessibility"), it seems it muddies the terminology 
> to have software, hardware, and connection in this sentence that starts 
> with accessible.

I agree, I think it best to not mix these 2 concepts in this way, 
especially not in the first paragraph.

I also think the word "function" should be replaced with "ability" (as 
it was originally). All definitions of "function" are not relevant to 
what is being conveyed in this text.


>> The web radically changes the nature of disability - it removes 
>> barriers to communication and interaction. However, badly written web 
>> pages or technologies re-introduce these barriers.
> 
> *EOWG*: please comment on above paragraph.

I think Laura hit the mark with her comment on this part in her email 
this morning.


>> The web must provide equal access and equal opportunity to people with 
>> diverse abilities. Article 9 of the UN Convention on the Rights of 
>> Persons with Disabilities recognizes _web accessibility as a basic 
>> human right_.
> 
> *EOWG* - how do you think readers will react to "The web must provide 
> equal access and equal opportunity to people with diverse abilities." ?

I believe the version up at 
<http://www.w3.org/WAI/EO/Drafts/4betaW3org/accessibility-new-w3c20090825a> 
is better (although I would not keep the sentence enclosed in [] (no 
idea what you call those in English).


>> Keeping the web accessible to all is not only a matter of human 
>> rights; it also makes good business sense. Accessibility best practice 
>> substantially overlaps with best practice in disciplines such as 
>> mobile web design, device independence, multi-modal interaction, 
>> usability and search engine optimisation. Case studies show accessible 
>> websites achieving better search results, reducing maintenance costs, 
>> and increasing their audience reach, among other benefits. _Developing 
>> a Web Accessibility Business Case for Your Organization_ details the 
>> social, technical, financial, and legal benefits of web accessibility."
> 
> SLH: Like that it's shorter, too.

I prefer the version up at the aforementionned URL.


>> "What: Examples of Web Accessibility
>> Well designed websites and web tools can be used by people with 
>> disabilities. However, currently most are developed with accessibility 
>> barriers that make it difficult or impossible for some people to use 
>> them. Below are just a few examples."
>>
>> Suggest
>>
>> "What makes a website inaccessible?
> 
> *EOWG* - please comment on this as a subheading here.
> 
>> Properly designed websites and web tools present no barriers to many 
>> people with disabilities. Unfortunately, some are developed with 
>> accessibility barriers that make it difficult or impossible for some 
>> people to use them. Below are just a few examples."

I prefer the version up at the aforementionned URL.

I would add however that in the examples that follow, there seems to be 
a lack of balance with regards to the level of information. And, again 
for balance purposes, it would be best if we could provide visual cues 
for all examples, not just Alt text, if at all possible.

Also, specifically on the Alt text example, I think there could probably 
be a way of merging the info a bit. For example :

"Alt text is the classic example. Images should include equivalent 
alternative text in the markup/code. If alt text isn't provided for 
important images, that information is inaccessible, for example, to 
people who cannot see and use a screen reader that reads aloud the 
information on a page, including the alt text for the visual image.

Providing equivalent alt text for images ensures the information is 
available to everyone, including people who have turned off images on 
their mobile phone to lower bandwidth charges, people in rural areas 
with low bandwidth and people who are blind. And it's also available to 
technologies that cannot see the image, such as search engines."

I am sure the above could be improved. But one of the important changes 
proposed above is to replace "If alt text isn't provided for important 
images, the web page is inaccessible (...)" with "If alt text isn't 
provided for important images, that information is inaccessible (...)" 
because I am not sure we can technically claim that a whole Web page is 
innaccessible if there is a missing alt text.

Also, I wonder about the use of "important images". I understand what 
you are trying to convey but it sounds a bit subjective.

For the pod cast example, I would remove the second paragraph, it seems 
a bit unbalanced with the rest and introducing the question of fees in 
this document seems unstrategic. However, that would require a minor 
adjustment to the lead in of the next section. Also, there is a minor 
typo in the second sentence of the first paragraph : "proving" -> 
"providing".


>> "How: Make Your Website Accessible [whole section]"
>>
>> Suggest:
>>
>> "How to keep your web site accessible
>>
>> Many accessibility barriers can be easily removed. However, the 
>> techniques required are poorly integrated into some web tools, 
>> education, and development process. If you are new to accessibility, 
>> it takes some time and effort to learn the common issues and 
>> solutions. A starting place is the _Introduction to Web Accessibility_.
>>
>> Some accessibility barriers are more complicated and take more 
>> development time and effort to remove. W3C provides extensive 
>> resources to help with this, such as _Understanding WCAG 2.0: A guide 
>> to understanding and implementing Web Content Accessibility Guidelines 
>> 2.0_.
>>
>> Using _authoring tools_ that support accessibility makes it easier for 
>> website developers. _Browsers_ [link to UAAG?] also play a role in 
>> accessibility. _Essential Components of Web Accessibility_ explains 
>> the relationships between the different components of Web development 
>> and interaction.
>>
>> Reasons:
>> 1) title change, alters expectation... your site should be accessible 
>> already! (It isn't? Oops! Quick, go fix it!) *and* you need to work to 
>> keep it that way. Reflects the change of emphasis in WCAG2.0 to dated 
>> conformance.
> 
> SLH: I'm not convinced. :) "How to keep your web site accessible" 
> conflicts with "Many accessibility barriers can be easily removed."

I prefer the version at the aforementionned URL.

Finally, I reiterate that, for the content at the aforementionned URL, 
second paragraph, last sentence, it is preferable to convey that 
innaccessible ressources exclude people (and not "disable people"). I 
really do feel that it puts a negative spin on the state of disability 
that is unnecessary in this context.

Thank you and best regards,


Catherine

-- 
Catherine Roy
http://www.catherine-roy.net

Received on Wednesday, 26 August 2009 16:37:15 UTC