How many aspects of Drupal conform with the W3C's Authoring Tool Accessibility Guidelines (ATAG 2.0)?
If we can write each of those aspects up, we can help the Authoring Tool Accessibility Working Group (AUWG) of the W3C's Web Accessibility Initiative improve two important documents.
And while we're doing that, we can make it easier for Drupal themers and developers to understand what they can do—or, in some cases, must do—to ensure that Drupal remains accessible and continues to help people who use it create websites that are themselves accessible.
This post is not yet complete. Check back in a few hours. Or perhaps even tomorrow.
Background
In August, I brought Mike and Brandon into a discussion among participants in the W3C. The topic was how we could help the working group that is developing the next draft of ATAG 2.0 and a companion document that explains how to implement these guidelines.
In July, the working group released these drafts for public review and comment:
- The working draft of ATAG 2.0—in other words, the guidelines themselves
- The companion document, Implementing ATAG 2.0: A guide to understanding and implementing Authoring Tool Accessibility Guidelines 2.0
The working group wanted comments by no later than September 15, 2011, but I'll bet that if you found something significant to say, they would listen. More about that below.
I don't get it. Where can I learn more?
Perhaps the best way to join is to read up on the past discussion. Go to the working group's public archive to read the comments already submitted and the responses to them.
I have to stop here for now. I will come back and complete the comment in a few hours.
Comments
Possible Additions
Hello everyone,
I'm not sure if the following suggestions are on topic, but know they would help screen-reader users on the net.
How about adding the following provisions:
http://www.amazon.com/gp/aw/h.html
The text only link should be the first thing a Screen-reader announces when reading the page, and should be named something unambiguous like, "Screen-Reader users, click here to access the accessible version of this site" so there is no doubt what the user should do. For example, Google has a Screen-reader link, that says, "Screen-reader users, click here to turn off Google instant."
This is misleading, because some screen-readers work far more quickly and efficiently on Google search results, when Google Instant is left turned on.
Any site that relies on a Search Box for visitors or members to find what they are looking for:
Must have the curser pre-positioned inside the Search Box, so a user can type or paste in their text and hit enter.
If pre-positioning the curser isn't possible, then a hotkey, such as Alt + S, should be made available. For example, Wikipedia uses Alt +F
Other than Gaming sites, if a website uses web applications that are inaccessible, this fact must be reported to public list, which maintains an active list of incompliant sites, so accessibility software designers can protect their users against unnecessary crashes.
Thanks,
Richard
Accessibility is meant to be seamless
I don't think I'd appreciate being addressed in that fashion ("screen reader users:…"). It sounds a tad authoritarian. It would get pretty tedious and I'd feel like people are making an exception for me.
Accessibility is about a lot more than screen reader users, so it doesn't quite cover it anyway.
Most importantly, it's getting away from one Web and making ways for site builders do so. A copout. I don't know if many of you remember the days of "entry" homepages to sites which allowed you the choice of "Tables or No Tables", "Frames or No Frames" and we still see a little of "Flash or No Flash". It detracts from the seamless experience and makes you think about mechanics. You stop being a reader and start being a technician. Websites can be built accessibly. Rich features can be added in such a way that they are gracefully unnoticeable or seamlessly replaced if they aren't supported. There should not be duplicate versions of HTML websites because HTML is already accessible if you know what you're doing. Don't provide escape clauses from developing responsibly.
I still see "Upgrade your Flash Player" everywhere and it annoys me each time. I don't have a version to upgrade!
I also don't think it's reliable that screen reader users (or anyone really) uses a mouse. For that reason and others, "click here" should always be avoided.
So yeah, strongly opposed, I'm afraid. Sorry, a little ranty today :}
Cheers
Revised Suggestions
Point taken about screen-reader users being singled out. I don’t like it now either! But it's Google's expression, not mine.
Furthermore, Google's link makes it worse for screen-readers, when it implies the opposite. I search Google for "one Web accessibility" but found no results on the first 2-pages, so the concept hasn’t exactly caught on.
I did have second thoughts about using the word "ClickHere" but since practically every computer help guide in the known universe uses the word "click," I figured it would be better to focus on something less entrenched, and more widely understood and attainable, such as a TextOnly option. The point of the ClickHereToDoSomething link was to combine words into a single word-link, so the user knows what will happen if the link is accessed, and to avoid narration, such as "link use link this link link to link access link the link text link only link version link of link our link site." It's not only tedious, it interrupts the natural flow, and reduces overall comprehension of the page. The alternatives for links are unnatural pitch shifts, or to turn off link tips and guess where to "click" on everything.
I still think a TextOnly version is a viable alternative, especially if it works 20-times faster, has no java, flash, pictures, or videos to clutter it up, and makes the difference between using a site now, or not using it at all.
The TextOnly option should also apply to websites already bought and paid for, or for owners who don’t have the money to restructure their site. The TextOnly feature used to be popular, so old hand programmers could easily provide TextOnly versions without alienating anybody.
Also I did not say anything about converting html sites to TextOnly.
I don’t mean to imply that web authors shouldn’t be made aware of the importance of accessibility. However, a TextOnly option makes more sense than convincing every website owner to upgrade or comply with accessibility standards. It's fine to wish for the moon and stars, but in reality for the past 20-years, accessibility on the net has deteriorated, not improved.
Throughout this entire time, there has been plenty of talk about accessibility, and very few concrete results to point to as examples.
Having the curser pre-positioned inside search boxes would help anyone to use a site's Search feature more affectively. It eliminates the need for an extra click, and it makes more sense to type or paste in a Search query and hit enter, as opposed to tabbing all over a page, looking for a box that might not even be announced.
Is the purpose here solely to guide web-authors for the sites of tomorrow? Or is it to make as much of the net accessible as possible now?
Richard
accessibility is very attainable now
I agree, this is really the question. They are not exclusive alternatives. I am one who would prefer to lead than follow. If leading meant we leave users behind, then I wouldn't be in favour. But the standards are so brilliant in the way they provide for graceful degradation, that it's not necessary. People do waste their money on shonky developments unfortunately. There has to be some accountability. The thing is it will never change if we give them exit passes. I'd say that's why, as you say, these things haven't moved along in 20 years. Making allowances will only continue that.
Text-only pages were another of those page choices we used to have that I forgot to mention. I remember them having some appeal because users tended to have low bandwidth connections. Then most people learned that you could disable images in your browser. Works on any site.
Where I worked not so long ago, we used to see search as the last resort for users. If users need to search, your navigation and architecture has failed them. We examined search logs for pointers to improving IA.
I really feel there's a lot more to be said, but it's boring for most of us. I don't think this is aiming for the stars, it's just not that hard. When you look at site builders who say it's difficult, they are usually using a WYSIWYG or don't know the standards very well.
I really am sorry for being boring and petty. I know you mean well.
Not Text Only, Not Easy Either
Couple short points.
@richveg - Assistive technology works pretty well with HTML. I'd be surprised if there is any "Text Only" version of a website that gets even a fraction of the attention that the more graphical version gets. Most organizations don't have the $$ to support a mirror site and frankly accessibility just isn't important enough in the minds of most executives. Mind you if those executives start using mobile apps like:
http://www.wired.com/gadgetlab/2011/10/text-only-a-text-only-browser-for...
Then perhaps we'll see it getting a critical mass that makes maintaining a text only version viable. The idea of text only versions comes up from time to time, especially when running into difficult accessibility challenges like modal dialog http://drupal.org/node/1175830
It's an issue that keeps coming up but more than anything it comes up with folks who are looking for a simple solution to a complex problem. This tread is supposed to be about ATAG & it is important to try to stay focused on it. @richveg - please read up on it here http://www.w3.org/WAI/intro/atag.php
@hughbris - I had to respond to "it's just not that hard". Having worked on improving accessibility in Drupal for the last 3 years I have to say that is a pretty dangerous assertion to make. There's lots of low hanging fruit in web accessibility (Alt Tags come to mind). However, there's are many layers to this issue and it's really difficult to find simple answers to a lot of problems. Even in Drupal 7 we haven't made it easy enough for folks to enter alt text & remind them of the advantages of adding them. There's a lot more we can do to the interface in Drupal 8 to make it more natural for people to describe their images.
Technology is moving so quickly and published best practices are not. This gets even harder to deal with when there is no common standards for assistive technology parsing the content. There are so many simple things that folks can do, like running their site through the WAVE toolbar:
http://wave.webaim.org/
However, I do get worried when the difficulties of producing accessible sites are downplayed. It's not rocket science, but it isn't a no-brainer either. I tried to summarize a good approach here and would be interested in your feedback:
http://openconcept.ca/blog/mgifford/web-accessibility-evaluation-methodo...
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
you're right
@mgifford, "It's not that hard" was a harsh generalisation, where I guess I was mainly referring to the sorts of issues @richveg raised (and thinking of some awful solutions I've seen). It does work on many levels. Alt text is technically easy, but difficult for many people to do well, and a challenge to know what role authoring tools should play, for sure. Great example.
I'd love to take a look at your post and maybe respond to other statements when I have a bit more time up my sleeve.
No rush
@hughbris this is an issue isn't going anywhere, no rush. Interested in your feedback when you have a chance.
@richveg hope you've found this an interesting introduction to accessibility issues.
Can we get back to "Documenting successful implementations of ATAG 2.0 in Drupal"?
--
OpenConcept | Twitter @mgifford | Drupal Security Guide