E-mail List Archives
Thread: Re: Is there a better solution forwebaccessibilitystatements?
Number of posts in this thread: 1 (In chronological order)
From: smithj7
Date: Wed, Feb 14 2007 9:00PM
Subject: Re: Is there a better solution forwebaccessibilitystatements?
No previous message | No next message
I am always learn new info on this list. I work for a state agency and all
of us have the same accessiblity statement (it is a required link). So I
never had realized that having or not having one was an issue. I also
didn't realize The WCAG 2.0 includes the concept of a "baseline" which is
attached to a "conformance claim". I have only been studying the web check
points. I need to go back and do some more reading.
----- Original Message -----
From: "Philip Kiff" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, November 03, 2006 12:49 PM
Subject: Re: [WebAIM] {WebAim] Is there a better solution for
webaccessibilitystatements?
> Sherrie wrote on 3 November 2006 11:44:
>> Accessibility statements have always bothered me, but it's only till
>> now that I have gotten around to writing something about it.
>>
>> It's available on my blog -
>> http://tinyurl.com/uuhr8
>>
> http://www.rosiesherry.com/blog/show/Showing+web+accessibility+statements+th
> e+door
>>
>> Feedback welcomed and appreciated!
>
> I must confess that I don't quite understand where the negative reaction
> against accessibility statements is coming from. I have noticed that it
> has
> been discussed in other forums, and so I realize that Sherrie is not alone
> in feeling that they are not very useful. However, to extend arguments
> about the lack of usefulness of such pages into an campaign against them
> (perhaps intended to be tongue-in-cheek?) seems like an over-reaction to
> the
> situation.
>
> To convince me that a campaign against Accessibility Statements is a good
> idea, one would have to demonstrate that they are producing a negative
> effect, not just that the statements are useless. If accessibility
> statements serve even a small fraction of people who face accessibility
> issues browsing the web, then they serve a purpose. The absolute value of
> that purpose may be disputed, but there is no negative effect from having
> a
> page that serves only 1-2% of site visitors.
>
> Your blog overlooks one valid reason behind having an accessibility
> statement: these statements are public relations tools that form part of a
> marketing/public relations strategy for an organization or website. Even
> if
> no one with a disability or alternative user agent ever reads your
> Accessibility Statement, having one on your site makes a public statement
> about your organization.
>
> An Accessibility Statement can also be seen as your participation in a
> kind
> of public awareness campaign about web accessibility generally. The vast
> majority of web surfers still do not know that there is such a thing as
> "web
> accessibility". In that context, even a poorly crafted Accessibility
> Statement serves to raise the profile of web accessibility generally,
> merely
> by putting the words "web" and "accessibility" beside one another.
>
> Who reads these things? Well, not all Accessibility Statements are
> written
> for non-technical users. I for one often end up taking a look at a site's
> Accessibility Statement because I'm interested in how they are portraying
> themselves publicly with respect to web accessibility. To me, that is a
> valid function for such statements and I learn as much about an
> organization
> by reading an uninformative Accessibility Statement as I do by reading a
> well-crafted one. I find that it is rare these days for a web
> designer/developer of a standard company/government/NGO site to actually
> explain how they have designed a site or why. As a fledgling designer,
> such
> Accessibility Statements sometimes serve as the only glimpse into the site
> designer's creative process that I get. Once in a blue moon, someone puts
> some information into the source code or notes in the CSS file as well,
> but
> that's about it, unless you are looking at a site designed for web
> designers
> instead of a standard public/corporate site.
>
> Quoting from Sherrie's blog:
>> I do agree, for more complex and interactive sites, there may be a
>> requirement to offer assistance, but why not have it in a help area
>> which addresses multiple issues. You could call it 'help', 'using this
>> site' or 'about', it would be a central area of help and still be easy
>> to find and of use to everyone who is interested.
>
> Certainly, such information could be placed on a page along with other
> "help
> with this site" info, and identifying it as specifically related to
> "accessibility" on that page serves the same function of raising awareness
> amongst the general browsing population. The difference between this and
> an
> Accessibility Statement seems to be simply length or prominence, not
> function. I think you would find that based on the length of the content
> of
> most current Accessibility Statements, the reasonable unit size for that
> information is one x/html page.
>
> I would discourage you or others from spending time and energy campaigning
> against the use of Accessibility Statements. Instead, I would encourage
> you
> to post up an explanation of how to create a useful one in those cases
> where
> you think they are useful, and then include some extensive details about
> where you think they are not useful and why. Then maybe future
> Accessibility Statements might be improved.
>
> Lastly, Accessibility Statements are not going away. The WCAG 2.0
> includes
> the concept of a "baseline" which is attached to a "conformance claim".
> Such conformance claims are very similar to current Accessibility
> Statements
> (or at least to the overly technical ones!). Gez's has written up a good
> summary of how the baseline concept works over at Juicy Studio (though
> there
> is no comment there about how such conformance claims would appear or how
> they relate to current Accessibility Statements):
> http://juicystudio.com/article/wcag-baseline-concept.php
>
> Phil.
>
>