Comments on: Site Design For Accessibility – 15 Rules http://webdevnews.net/2009/01/site-design-for-accessibility-15-rules/ News For Web Developers Sat, 04 Sep 2010 08:38:15 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: WilhelmR http://webdevnews.net/2009/01/site-design-for-accessibility-15-rules/comment-page-1/#comment-1957 WilhelmR Tue, 27 Jan 2009 12:57:41 +0000 http://webdevnews.net/?p=349#comment-1957 Great article, really interesting. This is a topic that should be more prominent in design/accesibility/usability sites. Great article, really interesting. This is a topic that should be more prominent in design/accesibility/usability sites.

]]> By: Jared Smith http://webdevnews.net/2009/01/site-design-for-accessibility-15-rules/comment-page-1/#comment-1929 Jared Smith Sat, 24 Jan 2009 21:12:20 +0000 http://webdevnews.net/?p=349#comment-1929 I admit my first comment was much too harsh. There are lots of good tips here - and I'm especially glad to see that you are addressing accessibility. You're absolutely right about % sizing and accesskeys - no clear answer there. Hopefully our comments helped clarify a few things. I admit my first comment was much too harsh. There are lots of good tips here – and I'm especially glad to see that you are addressing accessibility. You're absolutely right about % sizing and accesskeys – no clear answer there. Hopefully our comments helped clarify a few things.

]]> By: SiteBusinessZone http://webdevnews.net/2009/01/site-design-for-accessibility-15-rules/comment-page-1/#comment-1927 SiteBusinessZone Sat, 24 Jan 2009 17:55:44 +0000 http://webdevnews.net/?p=349#comment-1927 Hiya thanks for the comments. Firstly I would like to say that's the point about good commenting was more aimed at making your code more usable to other users, I shouldn't have mentioned screen readers in there. As far as visual elements go, I agree, use them all you want, but don't have an image containing a big block of important text and no other way for it to be accessed because that content will be missed by some users. Aural CSS as you said is just an extra you can add in. I was unaware that screen readers would not read the skip to content button when hidden, my bad. Also there is always a lot of debate as to weather % based sizing and changing the values for the access keys are a good idea. I would take these out as they are so open to debate but I can't edit the post now. I would also make some other changed based on the feed back here. Nice advice Aaron D. Campbell thanks and Kel Smith I agree that validation a lone is no way to judge your sites accessibility. I nearly always separate JS files and include them in the header, I should have mentioned this also. I shall be making some changes to my article before posting it else ware. I hope at least some of it was useful though! Thanks guys. Hiya thanks for the comments. Firstly I would like to say that's the point about good commenting was more aimed at making your code more usable to other users, I shouldn't have mentioned screen readers in there.

As far as visual elements go, I agree, use them all you want, but don't have an image containing a big block of important text and no other way for it to be accessed because that content will be missed by some users.

Aural CSS as you said is just an extra you can add in.

I was unaware that screen readers would not read the skip to content button when hidden, my bad.

Also there is always a lot of debate as to weather % based sizing and changing the values for the access keys are a good idea. I would take these out as they are so open to debate but I can't edit the post now. I would also make some other changed based on the feed back here.

Nice advice Aaron D. Campbell thanks and Kel Smith I agree that validation a lone is no way to judge your sites accessibility.

I nearly always separate JS files and include them in the header, I should have mentioned this also. I shall be making some changes to my article before posting it else ware. I hope at least some of it was useful though!

Thanks guys.

]]> By: Kel Smith http://webdevnews.net/2009/01/site-design-for-accessibility-15-rules/comment-page-1/#comment-1926 Kel Smith Sat, 24 Jan 2009 17:35:18 +0000 http://webdevnews.net/?p=349#comment-1926 It isn't so much that access keys aren't useful in concept; it's more that in practice, they tend to interfere with key controls inherent to screen-reading software. Screen-reader users need to toggle between different modes to navigate pages and to do such things as fill out forms, etc, and sometimes the access keys create some conflicts. While opinions vary and I don't personally endorse their use as an imperative to accessibility, the UK government has a set of standards for access keys: S - Skip navigation 1 - Home page 2 - What's new 3 - Site map 4 - Search 5 - Frequently Asked Questions (FAQ) 6 - Help 7 - Complaints procedure 8 - Terms and conditions 9 - Feedback form 0 - Access key details It isn't so much that access keys aren't useful in concept; it's more that in practice, they tend to interfere with key controls inherent to screen-reading software. Screen-reader users need to toggle between different modes to navigate pages and to do such things as fill out forms, etc, and sometimes the access keys create some conflicts.

While opinions vary and I don't personally endorse their use as an imperative to accessibility, the UK government has a set of standards for access keys:

S – Skip navigation
1 – Home page
2 – What's new
3 – Site map
4 – Search
5 – Frequently Asked Questions (FAQ)
6 – Help
7 – Complaints procedure
8 – Terms and conditions
9 – Feedback form
0 – Access key details

]]> By: Aaron D. Campbell http://webdevnews.net/2009/01/site-design-for-accessibility-15-rules/comment-page-1/#comment-1925 Aaron D. Campbell Sat, 24 Jan 2009 17:31:10 +0000 http://webdevnews.net/?p=349#comment-1925 I just thought I'd point out that putting your javascript at the END of the document (just before </body>) rather then the head is a better idea. The page will load sooner. I know that the javascript then won't work until after the page is fully loaded, but it's still nice for the user to see something begin to render as quickly as possible. I just thought I'd point out that putting your javascript at the END of the document (just before </body>) rather then the head is a better idea. The page will load sooner. I know that the javascript then won't work until after the page is fully loaded, but it's still nice for the user to see something begin to render as quickly as possible.

]]> By: Kel Smith http://webdevnews.net/2009/01/site-design-for-accessibility-15-rules/comment-page-1/#comment-1924 Kel Smith Sat, 24 Jan 2009 16:46:29 +0000 http://webdevnews.net/?p=349#comment-1924 Code validation alone won't guarantee accessibility. Well crafted content structures are certainly an important consideration (if not the most important). To ensure that you're meeting specific accessibility benchmarks, however, you still need to test against the use case. People with disabilities arrive at a site with a widely broad array of capabilities and expectations. One other item related to validation badges and "site info" pages: if you write an accessibility statement, don't be surprised if people completely ignore it. Few users I've spoken with have ever taken the time to read one on a site. People who rely on screen readers are just as impatient as anyone else - in fact, more so in many instances. Equivalency is the goal. Code validation alone won't guarantee accessibility. Well crafted content structures are certainly an important consideration (if not the most important). To ensure that you're meeting specific accessibility benchmarks, however, you still need to test against the use case. People with disabilities arrive at a site with a widely broad array of capabilities and expectations.

One other item related to validation badges and "site info" pages: if you write an accessibility statement, don't be surprised if people completely ignore it. Few users I've spoken with have ever taken the time to read one on a site. People who rely on screen readers are just as impatient as anyone else – in fact, more so in many instances. Equivalency is the goal.

]]> By: Jared Smith http://webdevnews.net/2009/01/site-design-for-accessibility-15-rules/comment-page-1/#comment-1923 Jared Smith Sat, 24 Jan 2009 16:29:14 +0000 http://webdevnews.net/?p=349#comment-1923 - <alt>+<shift>+<key> is a common shortcut in many screen readers. Accesskeys are a great idea poorly implemented. If there were a standard set of accesskeys, they'd be awesome. But there is no way of ensuring no conflicts. - Screen readers will likely always ignore display:none and visibility:hidden. And rightfully so. You can hide content visually, but have it read by screen readers - <a href="http://webaim.org/techniques/css/invisiblecontent/" target="_blank">http://webaim.org/techniques/css/invisiblecontent...</a> - I mis-wrote. % sizes for page elements (like widths/heights) and font sizes is good. I was thinking ems. ems for page elements can be problematic. Regardless of what is used, the layout should support increased font sizes. - <alt>+<shift>+<key> is a common shortcut in many screen readers. Accesskeys are a great idea poorly implemented. If there were a standard set of accesskeys, they'd be awesome. But there is no way of ensuring no conflicts.
- Screen readers will likely always ignore display:none and visibility:hidden. And rightfully so. You can hide content visually, but have it read by screen readers – http://webaim.org/techniques/css/invisiblecontent...
- I mis-wrote. % sizes for page elements (like widths/heights) and font sizes is good. I was thinking ems. ems for page elements can be problematic. Regardless of what is used, the layout should support increased font sizes.

]]> By: Gilzow http://webdevnews.net/2009/01/site-design-for-accessibility-15-rules/comment-page-1/#comment-1922 Gilzow Sat, 24 Jan 2009 16:19:14 +0000 http://webdevnews.net/?p=349#comment-1922 actually, #11 wont work for most screen readers. So if you use "display:none" the screen reader wont see it either. Download a trial of JAWS and try it out. Your hidden (via CSS) skip to content link will be gone. The best method we have found is to set your skip nav link to display, but offset it to the left by 99999px. This way it is visible as far as the screen reader is concerned, but wont be visible to your sighted users. As Jared mentioned, screen readers are not going to pick up your comments. Again, the screen reader will read what the browser indicates is on the screen. Your comments dont appear in a browser, so they wont be read. With #8, you should strive to follow progressive enhancement with equal access when designing for accessibility. You should also separate your javascript from your markup. Instead of using inline javascript (i.e. onmouseover="somejavascript", or <a href="#" onclick="somejavascript"), keep all of your javascript in the head (or better yet, separate files) and add event listeners for everything you need to do. And make sure that any information your javascript provides is also available to those who dont have javascript. not only will this help with accessibility, it will also help your readers who are accessing the site with mobile devices. actually, #11 wont work for most screen readers. So if you use "display:none" the screen reader wont see it either. Download a trial of JAWS and try it out. Your hidden (via CSS) skip to content link will be gone. The best method we have found is to set your skip nav link to display, but offset it to the left by 99999px. This way it is visible as far as the screen reader is concerned, but wont be visible to your sighted users.

As Jared mentioned, screen readers are not going to pick up your comments. Again, the screen reader will read what the browser indicates is on the screen. Your comments dont appear in a browser, so they wont be read.

With #8, you should strive to follow progressive enhancement with equal access when designing for accessibility. You should also separate your javascript from your markup. Instead of using inline javascript (i.e. onmouseover="somejavascript", or <a href="#" onclick="somejavascript"), keep all of your javascript in the head (or better yet, separate files) and add event listeners for everything you need to do. And make sure that any information your javascript provides is also available to those who dont have javascript. not only will this help with accessibility, it will also help your readers who are accessing the site with mobile devices.

]]> By: Aaron D. Campbell http://webdevnews.net/2009/01/site-design-for-accessibility-15-rules/comment-page-1/#comment-1921 Aaron D. Campbell Sat, 24 Jan 2009 16:16:21 +0000 http://webdevnews.net/?p=349#comment-1921 Just a few points of contention: I don't know that I agree on the access key one. I think they are extremely useful, and I haven't heard of problems with them interfering with screen readers. If they do, then screen readers should have thought about that before they used those shortcuts. For example, in Firefox you use <alt>+<shift>+<key>, which isn't a common shortcut combo. As for making a "skip to content" link and hiding it, I agree that it seems pointless. First, the goal is to give disabled users the same experience that your users who are not disabled enjoy. Second, even if screen readers read it now, eventually they'll learn to ignore hidden content. Lastly, these links are also useful for mobile users who have to page down through 5 screen of header and sidebar to get to your content. Saying that % sizes for fonts are bad because they could overlap is like saying that images are bad because they could be ugly. It's true that they COULD overlap, and it's true that the images COULD be ugly. However, that doesn't mean they WILL be. If done properly, this will help sighted people with poor vision to see your content. Just a few points of contention:
I don't know that I agree on the access key one. I think they are extremely useful, and I haven't heard of problems with them interfering with screen readers. If they do, then screen readers should have thought about that before they used those shortcuts. For example, in Firefox you use <alt>+<shift>+<key>, which isn't a common shortcut combo.

As for making a "skip to content" link and hiding it, I agree that it seems pointless. First, the goal is to give disabled users the same experience that your users who are not disabled enjoy. Second, even if screen readers read it now, eventually they'll learn to ignore hidden content. Lastly, these links are also useful for mobile users who have to page down through 5 screen of header and sidebar to get to your content.

Saying that % sizes for fonts are bad because they could overlap is like saying that images are bad because they could be ugly. It's true that they COULD overlap, and it's true that the images COULD be ugly. However, that doesn't mean they WILL be. If done properly, this will help sighted people with poor vision to see your content.

]]> By: Jared Smith http://webdevnews.net/2009/01/site-design-for-accessibility-15-rules/comment-page-1/#comment-1920 Jared Smith Sat, 24 Jan 2009 15:54:37 +0000 http://webdevnews.net/?p=349#comment-1920 Sorry, but there's some pretty BAD advice in this article! #2 - HTML comments are NEVER read by a screen reader (unless said screen reader user likes listening to HTML source) #4 - Use visual elements all you want, just provide the same content in text (typically via alternative text for images) #6 - Title, by definition, is for supplemental content. Don't add just cuz. It is typically ignored by screen readers, but if it is read (or seen) it should provide addition, non-vital information about the link. Don't make it redundant with the visible text. #9 - You can use scripting on menus, just ensure that it works with a keyboard, screen reader, and with javascript disabled. #10 - Aural CSS is not supported by any major screen reader. Implement it if you want, but the page should be accessible without it. #11 - How will sighted keyboard-only users see the "Skip to content" link if it's hidden. If you hide it with display:none or visibility:hidden, screen readers will ignore it. #12 - Accesskeys are usually a bad idea. They will interfere with browser or screen reader shortcut keys. #15 - % for page element sizes can be a bad idea. If you increase your font size a bit, things may overlap or cause horizontal scrolling. In general, just make sure the page is readable and usable when fonts sizes are increased. I know your intentions are good, but this article should have been better researched. Sorry, but there's some pretty BAD advice in this article!
#2 – HTML comments are NEVER read by a screen reader (unless said screen reader user likes listening to HTML source)
#4 – Use visual elements all you want, just provide the same content in text (typically via alternative text for images)
#6 – Title, by definition, is for supplemental content. Don't add just cuz. It is typically ignored by screen readers, but if it is read (or seen) it should provide addition, non-vital information about the link. Don't make it redundant with the visible text.
#9 – You can use scripting on menus, just ensure that it works with a keyboard, screen reader, and with javascript disabled.
#10 – Aural CSS is not supported by any major screen reader. Implement it if you want, but the page should be accessible without it.
#11 – How will sighted keyboard-only users see the "Skip to content" link if it's hidden. If you hide it with display:none or visibility:hidden, screen readers will ignore it.
#12 – Accesskeys are usually a bad idea. They will interfere with browser or screen reader shortcut keys.
#15 – % for page element sizes can be a bad idea. If you increase your font size a bit, things may overlap or cause horizontal scrolling. In general, just make sure the page is readable and usable when fonts sizes are increased.

I know your intentions are good, but this article should have been better researched.

]]>