Web Accessibility Gone Wild presents a wide variety of mistakes, misconceptions, over-indulgences, intricacies, and generally silly aspects of modern accessibility.
Web Accessibility Gone Wild presents a wide variety of mistakes, misconceptions, over-indulgences, intricacies, and generally silly aspects of modern accessibility.
Hi
You say about alt tags for decorative images that are not “hidden” by CSS – “and most often, this means alt=”” for these types of images”. In a perfect world I would agree, but unfortunately so many webdesigners forget to add alt tags to important images that when I come across alt=”” I am not sure if that is because the image is not important or the designer has forgotten. I would much rather hear “alt equals photo of my cat” than “alt equals blank”. At least I then know that I am not missing out.
Richard
Great article Jared. I wasn’t aware of the issue with “forms mode” and screen readers possibly not reading content.
On fixing screen reader deficiencies, you may be able to use aural style sheets such as the ‘speak-punctuation’ element to help with some of these issues. See Web Axe podcast #58 for more on this.
Also, note that there is still some dispute over the longdesc attribute in HTML5.
Hi Jared, good article!
I have to repectfully disagree with parts of your guidance on the use of the title attribute. I think it is useful and appropriate to use the title attribute to label controls in situations where there is not a need for a text label, such as in controls contained within data tables. WAI-ARIA for example, makes use of the title attribute to provide the accessible name value to AT. It is a technique that we recommend for use in web applications especially.
steve faulkner wrote:
I mostly agree. With form controls in a table, there is usually another way of discerning the functionality of the form items – the table headers. In this case, title really is providing additional/supplementary accessibility information. In other words, if you remove title, it’s still can be accessible (though not optimally so).
In cases where title is the only means of providing the accessibility, I believe this goes beyond the purpose of the title attribute as defined. I do admit, though, that this is a rather pedantic and strict application of HTML standards and isn’t so much an accessibility issue. If it works, use it – I just believe hidden labels work better than title in most cases.
Hi Jared,
My only complaint is that #compliant is twice in the document. I was going to send an info to colleagues and pointing them directly to “Accessibility > Compliance” and it seems that the same name is used for “Noncompliant HTML != Inaccessible”.
I’m going to let them look through the article without giving them the anchor so as not to lose them (some use screen readers).
Feel free to delete my comment when it’s not appropriate anymore 🙂
And thanks anyway for the whole article, it’s very good and comprehensive.
Hadn’t heard the word ‘agregious’ before…
Stéphane, the anchor has been fixed. The link should be to #compliance.
Dave, the misspelling has been corrected.
This article may get some new readers (and traction) as it’s link was recently re-posted in the LinkedIn Web 2.0 Accessibility Forum. In reading it now – I think for the first time – I’m thinking some of the content may be a little dated and just wondering if a refresh is in order.
Adding to the current discussion I would hope you would include info about the various CMS’s out there that have become the norm and how they direct, or misdirect, the process of adding ALT text content. Without writing my own dissertation about this, my observation is that different CMS’s handle ALT text in different ways and in some cases prevent the user from even creating the null ALT option. My belief is that 95%+ of images on the web are “pretty pictures” that should be coded with the null, but without this capacity in the CMS, we are forced to have to create some pretty stupid ALT text in order to simply add any image. The image of the “smiling lady” made me think of this.
Also, I thought that the Long Desc was dead and buried. Surprised to even see it here.
Cheers!
~j
Dear Mr. Smith,
Recently, I have gone through this article and found it useful. Thanks for sharing valuable information with us.
There are few sections with which I am not agreed upon and presenting my views below:
1. Accessibility options are for sissies – Here you have questioned why to duplicate the functionality of a browser in a web application? – Isn’t it good to have alternative options? It will allow user to re-size the font size more than permitted limit of browser.
Sometime back I was visiting a forum post where users were discussing the way to remove default browser options. Some of them even have provided technical solution. (I can’t comment on correctness of solution). If it is possible then in such case having such features in application could be useful; although, it is very rare case.
I am curious to know how providing features like sizing or scaling of the page content can make page less accessible.
2. Accesskeys and tabindex – As I understand, Tab indexing is a good idea to help users with navigation who are dependent on keyboard only. I have seen many scenarios where user was navigating randomly on the form because tab indexing was not implemented. What kind of problem tab index can introduce? What are the alternative options for it?
I am interested to learn more about the accessibility so that I can help the testing community. Your answers will help me to learn more 🙂
Thanks in advance.
Regards,
Mohit Verma