Site Design For Accessibility – 15 Rules
Why is accessibility important?
Legal issues: in today’s internet orientated society care must be taken to ensure websites are not discriminative against impaired users such as the blind or partially sighted. Building websites which may be considered discriminative could lead to law suits which obviously we want to avoid.
Maximizing audience: the more accessible a website is the larger the potential user base, simple as that.
Maximizing potential for profit: the larger the potential user base is, the larger the potential customer base is.
Search engine compatibility: generally speaking a more accessible website is going to be easier for a search engine to index then an inaccessible website.
The 15 first rules for accessibility:
1. Write good source code
This is not necessarily required to build an accessible website but I feel it is a very important element of good site design so I’ve put it at the top of the list. Clean, well formatted code can save hours of headache, make it easier to find problems when something is wrong and provide a much stronger base for implementing accessibility changes and additions.
A good code structure often reduces the number of lines of code, meaning your pages will load quicker and use less bandwidth.
Weather it be XHTML, HTML, PHP , JavaScript or Cling-on, well written code is the foundation of any accessible site.
2. Use comments well
Good use of comments should be used to supplement well written source code. Comments should be concise and well written as they made end up being read by another developer or to an end user by a screen reader.
It is also advisable to remove any silly comments which may have been entered into your source code before release as they may cause confusion down the line.
3. Use a sensible page layout
This is just common sense really, there is no point having your main content in a narrow column along the left with a menu underneath and a bunch of images dotted about the page. Make sure your layout makes logical sense and your visitors can find what they are looking for without trying too hard. If a user can’t quickly discern navigation and main content they will leave.
4. Do not rely on visual elements (colors/images/video) to convey information
This point is obvious; if half your information is presented in images a blind user with a screen reader will miss half your information. Try to use text and CSS styling as much as possible in place of images, video and color information.
General Rule: Use visual content only as long as it does not contain information required to understand the content of the web page.
5. Separate styles and content!!
Separate your websites into styles and content, CSS and (X)HTML. This is important for well formatted code, ease of development and so that users with screen readers don’t have to listen to the styling of each object on a web page.
6. Give links context + titles
When creating a link try to create a meaningful caption for it, further more try to provide a label for the link.
DO:
<a href=”TideChart.php” title=“Tide Chart”>View our tide chart</a>
DON’T:
Tide Chart: <a href=”TideChart.php”>click here</a>
7. Use user-friendly URLs
Try and make your URLs follow a memorable pattern which makes sense to a human user.
DO:
http://www.site.com/en/plaster-board/large/index.html
DON’T:
http://www.site.com/en/pb/l/index.html
8. Use device independent scripts
You should be aware that not all users have a mouse, so if you are using triggers such as onmousedown you may wish to consider an alternative or you could use onmousedown in combination with onkeydown.
9. Use CSS instead of scripts for menus
Whatever you are thinking of using a script for on your menu be sure you can’t do it using CSS. A menu which uses JavaScript will cease to function properly if the visitor doesn’t have JS enabled.
#menu a {
display:block;
color:#791E27;
text-decoration:none;
font-size:1.1em;
cursor:pointer;
}
#menu a:hover {
display:block;
color:#fff;
background-color:#D92026;
text-decoration:none;
font-size:1.1em;
font-weight:bold;
cursor:pointer;
}
Remember you can easily create drop down, pop-up and fly out menus using just CSS and (X)HTML. Just do a good search.
10. Use aural CSS
If you think your site is likely to be read by someone with a screen reader there are some elements you can define in your CSS which effects the screen reader’s settings.
Some of these are voice-family, volume, richness, stress, cue-before, cue-after, pause.1
11. Provide a ‘skip to content’ button at the start of the page
It is very common for websites these days to have a header and a menu at the start of every page. This means that users with a screen reader have to listen to your header and menu every time they go to a new page.
The solution to this is a ‘skip to content’ button or link at the start of the page. The link can be hidden using CSS.
<a href=”#main_content” title=”main content” class=”hidden”>Skip to main content</a>
Alternatively you could use an image containing only the background colour in the top left of the page to be your link.
12. Provide main menu access keys and an accessibility page
Access keys allow people to access your menu items using a keyboard short cut, great for people will no mouse.
<a href=”index.html” title=”home” accesskey=”h”><em>H</em>ome</a>
Note: I have surrounded the H in the <em> element which would be styled in CSS to make the H stand out.
em{
font-style:italic;
}
Create a site info page which lists the access keys on your site. This is where I also put my W3C validation badges.
13. Check the finished product with no CSS enabled
Disable your style sheet somehow and make sure your layout and content still makes sense. Get someone who hasn’t seen your styles-enabled site to do this too.
14. Validate HTML + CSS
Use W3C validators for (X)HTML and CSS, valid code ensures compatibility and the validation process will probably help you pick up any silly errors you previously missed.
15. Use relative sizes and positioning
Using relative sizes and positioning allows visitors to see your whole page regardless of their screen size/resolution/browser window size. Use EMs for font sizes, and % for page element sizes.
Things to avoid
1. Frames
Frames and iframes are a bad idea when it comes to accessibility because screen readers can often find it difficult to determine which frame is the main frame and focus can become confused.
Frames can also cause problems with book marking and the accuracy of URLs.
2. Pop-ups
Pop-ups are annoying and most users won’t see them anyway as most modern browsers have pop-up blockers.
3. Automatic refreshes and automatic re-directs
These are no good for accessibility. “this page will be redirected in 5 seconds”, what if the user can’t read that message in 5 seconds?
4. Placing distractions and un-related content on your website
Flashing text, random images and scrolling elements can be annoying as well as distracting for your visitors, meaning they don’t focus on the important content of your site, and probably end up leaving.
Related Posts:
12 Responses to “Site Design For Accessibility – 15 Rules”
Leave a Reply
Recommended by Web Dev News
I'll be honest, this could have been a "10 things" list rather than 15…some of these were a bit of a stretch. However, the ones that weren't a stretch were extremely good! Access keys, skip to content links, relative font sizes, etc are all things a developer must know.
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.
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.
- <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.
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
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.
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.
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.
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.
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.
Great article, really interesting. This is a topic that should be more prominent in design/accesibility/usability sites.
It’s really an informative and helping article for all the concerned people. I think it will help all the persons who want to design their websites and doesn’t know much about the relative issues.