I was listening to a recent episode of Hanselminutes where Scott Hanselman was discussing accessibility in web applications and it got me thinking about accessibility in my own applications.
We all understand the importance of semantic markup in our web applications as it relates to accessibility but what about other simple enhancements that can be made to improve the user experience for disabled users?
In the episode, there were a number of times where I slapped my forehead and said "Of course! Why haven't I done that?" In particular, Scott talked about a website that placed a hidden link at the top of a web page that said "skip to main content". The link will only be visible to people using screen readers and it allows their screen reader to jump past menus and other secondary content. It's such an obvious improvement yet it's easy not to think of it.
There is more to accessibility and the overall user experience than simply creating valid XHTML and calling it a day.
What are some of your simple tricks for improving the user experience for the vision impaired?
Creating accessible pages is something that is hard to think about if you have never done it. However, once you learn the basic concepts it is very easy to do in 95% of the cases. I will mostly be repeating what others have said, but:
Only use tables for tabular data
Make sure you use the semantic tools available to you via HTML. This means using TH with a scope attribute. Use <em> instead of <i> and <strong> instead of <b>. Use the acronym and abbrev tags. Use definition lists. I can expand on these things if anyone wishes.
One of the most important things is to use the label tag on input fields. For every input field, radio button, checkbox and textinput you should have:
<label for="username">Username:</label><input name="username" />
Add a "skip navigation" or "skip to navigation" depending on where big chunks of text are. If you are working on a government site this should be second nature that everything you're creating allows you to skip repetitive information.
Do not use colors for emphasis.
Ensure that all of your text is resizable. This pretty much means don't use "px" in your css.
I will re-emphasize this: create semantic pages. Use H tags for your titles. Use ul/li for navigation.
Use the alt attribute on all images. If you have a spacer gif... well.. don't. Otherwise, explain what the picture is of and what its significance is to the content it is associated with. don't use "a chart" as your alt tag. Use "Chart of YTD finances: $5,000 Q1, $4,000 Q2, $8,000 Q3" or something similar.
Provide closed captioning or transcripts for all audio and video components
The key here is to provide those with visual, hearing and motor impairments the same experience as those with standard physical capabilities. If you can't tab into a field, a screen reader can't either. If you can't click on the text next to a check box to select it, the screen reader doesn't know the text is related to the check box.
You should frequently view your site without stylesheets (ctrl-shift-s if you have Firefox and the Web Developer Toolbar) to see if the page makes sense. If it doesn't make sense to you as a sighted individual, it won't make sense to someone using a screen reader.
Check out Fangs
Fangs is an in-browser tool for Firefox that emulates what a screen reader “sees” when visiting a Web page. Its function is simple: to output a transcript of what a screen reader will read out to a user when a Web page is visited. It’s a helpful tool for quickly analyzing if you’ve structured your content effectively so that it’s understandable and usable by vision-impaired individuals, without forcing you to learn to use (and purchase) a screen-reader application such as JAWS or Windows Eyes.
It's been awhile since I've been at a job where we had to adhere to Section 508, but here's what I remember that hasn't been touched on by the other posters...
Only use tables for data. Do not use tables for layout if you can avoid it.
When using tables for data, your column headers should be nested in TH tags and you should use title and scope attributes. Your table tags should use the summary attribute.
Images should all have a value for the alt attribute that describes what's going on in the image and if the image serves no purpose (it's a shim image or something similar) then the alt attribute should be set to empty string.
Try using a text to speech reader and/or navigate only through the keyboard and/or turn off stylesheets. I believe you need to purchase JAWS, but I'm sure there are free screen readers out there. You need to experience a site through a screen reader to truly understand how difficult most web pages are to navigate without the cues that screen readers interpret.
"Vision impaired" includes colour-blindness. I used to work with someone who couldn't distinguish red from green too well, so any applications that used a traffic-light style interface was very difficult for him to use. In the industry we were working in, alerts in rows were colour-coded, so another form of display was useful for him, such as an extra column in the row with the text of the alert type ("emergency", "warning" etc).
Biggest problem with screen readers is usually tables to position things on your page. Screenreaders can't really handle those. Put stuff in div's in your html and put them in a sensible order. Then position the div's on your page with css. Use tables to display content that should be in a table.
The code for many web pages is structured as:
Header
Top Navigation
Left Navigation
Content
Footer
When structured this way, then the hidden link for "Skip to Main Content" is beneficial. However, with CSS layout, you may be able to reorder this so that you have:
Content
Header
Top Navigation
Left Navigation
Footer
You then use CSS positioning and floats to move these different elements around on the screen to make the page look the way you want it to look.
The main advantage to structuring a web page in this way is that if the browser doesn't support the CSS, then the content is first on the page. In addition to screen readers, this is beneficial for mobile devices and search engine spiders.
For partially partially sighted we need to make sure text is not excessivly small and contrasts the background color substantially. We should also make sure text is resizable by using relative sizing units such as em's rather than absolute units like px's (although, in my opinion, this is becoming less of an issue as browsers are increasingly favoring zooming over text resizing).
For users of screen readers, it's helpful to get a good idea of the way screen readers are actualy used. The following article presents guidlines based on observations of blind people browsing the web using screen readers; it's a little out of date now, but gives you a good feel for what will help screen reader users, and what won't:
http://redish.net/content/papers/interactions.html
Additionally, the American Foundation for the blind have a section of their website dedicated to advice for web developers on how to cater for vision impaired users.
In addition to the visually impared, we need to consider those with disabilities that prevent them from using a mouse, and also those with neurological disabilities. If anyone can provide resources giving advice on how to cater for those individuals, that would be great.
Related
Got a site with powerpoint presentations that the client wants embedded, the embedding is being done via google docs embed. I have been doing some accessibility testing, albeit not particularly in-depth but even with OS X screen reader it is not having any luck reading the slides. (I am aware slides are probably terrible for accessibility anyway). I can get the text content of the slides stripped out via the Google API, but I don't know if thats the best thing, to include it on the page below/above the iframe embed with one of the CSS tricks for hiding it from normal view?
I am aware of iframe title and aria-label but those seem to imply they are only to describe the contents of the iframe, which I am doing, but I need somewhere that can contain more text.
Has anyone got any good tips for the best way to deal with such things? Thanks!!
Embedding rich 3rd-party content in web pages poses many challenges.
When we put something like this in a web page, we typically think we're adding a bit of "content", but it often amounts to embedding a complex application; and the user interface, semantics, and presentation are outside of our control. In your case it's a presentation slide deck, but it could also be a Flash/Silverlight/Java applet, a slippy map, interactive SVG infographic, a 3D-panorama, virtual tour, zoomable image, chemical molecule viewer, or who-knows-what. (Note: I'm not familiar with the Google docs embed/API specifically, so most parts of my answer will address these rich content cases in general.)
Even if the embedded rich 3rd-party content/application is accessible today, there's no guarantee it will remain so after the 3rd-party system gets an update.
So what can you do? The safest thing might be to assume it's inaccessible, and consider the best way to provide an accessible alternative. The Web Content Accessibility Guidelines (WCAG) calls this a "conforming alternate version", and it sounds like you're already thinking along these lines.
An important caveat to all of this, is that the use of "conforming alternate versions" isn't considered ideal by many accessibility specialists. It's greatly preferred to make your main content accessible as you can.
Some relevant parts of WCAG:
Understanding conformance, especially the section about "Understanding Conforming Alternate Versions".
Technique G190: Providing a link adjacent to or associated with a non-conforming object that links to a conforming alternate version.
F19: Failure of Conformance Requirement 1 due to not providing a method for the user to find the alternative conforming version of a non-conforming Web page.
It's worth mentioning the 3rd-party content in your website's accessibility statement. Statement of Partial Conformance - Third Party Content offers guidance about that.
The crucial thing about conforming alternate versions, is that it's no use at all if the user isn't made aware of it, or isn't able to reach it.
Implementation-wise, there are a variety of approaches you might take. In many ways, providing an alternative for embedded rich content is similar to providing a long description of a complex image, or a transcript of a video. Have a look at these WAI tutorials for some ideas.
Web Accessibility Tutorials: Complex Images
Making Audio and Video Media Accessible: Where to Put Transcripts
I can get the text content of the slides stripped out via the Google API
It sounds like you're trying to automate the process. That's fine, but it might not give satisfactory results. Some things you should consider:
Is the text content alone going to be enough? Presentations often have images too. Did the author provide text alternatives for these images, and are they present in the text extracted via the API? If the author hasn't provided text alternatives for images in the slide deck, the text you get from the API won't be telling the whole story.
Not all text in slides carries the same weight. Some slides serve to introduce sections, some slides have headings. Does the text obtained from the API convey these relationships?
Lists are very commonly found in presentation. Does the text obtained from the API preserve this structure?
Slides sometimes contain links. Are these included in the text obtained from the API, so the links are available to everybody using the alternative version?
Slides sometimes contain tables and charts. How will the information in these be conveyed in your alterative version? Is the information included in the text obtained from the API?
Sometimes, presentation decks also contain rich 3rd-party embedded content themselves! A slide containing a video, or an animated GIF are examples of this. If so, you can find yourself with a much more complex challenge.
... and many other meaningful info and relationships. Quotations, code samples, etc.
If any of the above points give cause for concern, you will need to consider managing your alternative version manually.
The "conforming alternative version" has to conform to WCAG; if you just offer a choice of two non-conforming version, that doesn't satisfy WCAG.
include it on the page below/above the iframe embed with one of the CSS tricks for hiding it from normal view?
No, I wouldn't recommend that. I assume you're refering to visually-hidden text, using CSS utility classes such as .visually-hidden or .sr-only. It sounds like you're only thinking about screen reader users.
You need to offer the alternative version available to everybody, not just one group of users who you think will need it.
Many groups of users may experience difficulty using the rich 3rd-party embedded content. This includes people using the keyboard only, screen readers, magnifiers, speech control, switch access, or other tools. The conforming alternative version can be navigated like a normal web page though.
The 3rd-party content likely has a different visual style, and it may not be adaptable in the same way as the page it is embedded in. That can frustrate people who make use of browser zooming, text resizing, font preferences, reader mode, Windows high-contrast themes, viewport resizing, and other user-applied presentation changes. The conforming alternate version should be as adaptable as the rest of your site.
Rather than hiding the alternative version in a visually-hidden container, here are some other ways to present it. The first two are the simplest and most reliable.
Put it on the same page, just after the original content, visible to everybody.
Put it in a collapsible disclosure element just after the embedded content. A <details> element is an easy way to achieve this. This is useful if the alternative version is quite long.
Put it elsewhere on the same page, and tell users where to find it. An internal link can help here.
Put it on a separate page, with a link next to the embedded content. I'm less keen on this approach. Only use it if you can commit to maintaining both pages.
Provide a way for users to switch between the two versions. For example some buttons, or a tabbed UI. However, you must also ensure that the switching mechanism is accessible. That might mean a full-blown ARIA tabs implementation.
I am aware of iframe title and aria-label but those seem to imply they are only to describe the contents of the iframe
Giving the iFrame a useful name is important. It's also a useful mechanism to inform screen reader users that an alternative version is available. The WAI Complex Images tutorial linked above has some similar approaches. Example: <iframe title="Google Slides Presentation of FOO BAR BAZ. Link to text version follows this frame.">. This only helps screen reader users though; you still need to make the availability of the alternative version clear to everyone.
How committed are you to using Google Docs for displaying these slides?
Any accessibility enhancements that you'll be able to implement on Google Slides won't be very good.
One way around this whole thing is to offer PDF versions of the slides that have been fully-remediated for accessibility instead of using Google Slides. That would potentially be a single solution that could be accessible to all visitors. Going this route means that you wouldn't have multiple copies of the same slides to update, which could lead to a split in content if one gets updated and the other is forgotten.
If you're really set on having the slides embedded in the page, then you could offer both formats by applying aria-hidden to the embedded iframe and then hiding the PDF links from sighted users using CSS clip, or by positioning content off-screen.
I'm tasked with evaluating some legacy web pages (classic asp) for accessibility. You can assume the HTML is not perfectly formed and that it's loaded with inline javascript and that we make use of javascript libraries that vomit HTML to create dynamic features. It's a circus in there.
While I recognize that the obvious answer is to re-write the page(s), that's not an option in our given time tables. So I'm trying to find the best way to make the pages work with a screen reader. Here's what I think I know.
We can use JAWS scripting to instruct the browser how to read the page.
We can use ARIA attributes to give the pages better organization and structure.
Specifically, I'm trying to figure out:
Question 1) If a JAWS script is present, will it be used exclusively by the browser/screen reader and ignore any improvements I make in the underling HTML structure?
Question 2) Could some well-place ARIA attributes give the page enough structure so that the default screen reader properties will work in an acceptable manner (without a JAWS script).
Question 3) I suspect the tough answer is that I would need to do both, which I'm trying to avoid because we barely have the capacity to do just one. But we don't want to lose a customer, of course. :-(
Many thanks for any input.
Instead of explaining only to JAWS how to access your pages, use JavaScript to explain it to any Assistive Technology (AT) for the web. I expect the same effort, while it will profit way more users.
In a JAWS script you would need to describe ways to access DOM nodes that are not accessible. That would include
speaking out information that you have to find elsewhere on the page
adding keyboard navigation where it's missing
Both can be done in JavaScript, probably even easier (you'll need to address DOM elements).
What you will need to avoid is restructuring the DOM and changes to classes, since those are most likely used by the scripts that generate them.
But I'd expect that adding attributes and keyboard handlers will do no harm to the existing scripts. Beware of already existing handlers for focus or keyboard events, though.
I would recommend making a list of attributes and handlers you suspect to conflict with the existing scripts, and searching the scripts for these, like onkeypress or onfocus event handlers.
The absolute best way to make your application/site accessible is to use semantic HTML. It doesn't matter if that HTML is generated by asp or jsp or whatever.
If you have a table, use a <table>.
If you have a heading, use an <h2>.
If you have a list, use a <ul>.
Use <section>, <article>, <nav>, <aside>, <header>, <footer>, etc
That's how you create structure on your page that a screen reader user will appreciate.
If you can't use native HTML, then fall back to ARIA, but treat it like salt. A little bit greatly enhances the flavor but too much spoils the meal.
If you can't use a native <h2>, then make sure you use the appropriate role and attributes.
<div role="heading" aria-level="2">this is my custom h2</div>
If you can't use a native <header>, then make sure you use the appropriate role and attributes.
<div role="banner">my header stuff goes in here</div>
I would recommend totally forgetting about JAWS scripts. It doesn't matter if that's what the customer thinks they should focus us. It's not about that customer. It's about that customer's customers. The end users. They should be able to use whatever screen reader they are used to using and most comfortable with. That's the whole purpose of accessibility - making the site usable and accessible by as many people as possible using whatever assistive technology they are used to using.
Following the Web Content Accessibility Guidelines (WCAG) will lead you to that result.
UPDATE 2: Edited again to more clearly focus on visitors with disabilities
Is applying ARIA landmark roles alone a major accessibility improvement, or a half-measure that doesn't accomplish very much? Are there other relatively easy things a site can do to significantly improve accessibility?
By accessibility, I mean usability by people with disabilities, for instance visual impairment, difficulty using a mouse, etc..
By simple, I mean large-scale changes to page structure on the site's main templates, rather than hand-tweaked changes to each page.
For example, the one step of applying ARIA landmark roles is in reach for many sites, just by updating their blog or content management software templates. Doing the whole nine yards to annotate every widget’s interaction state is much harder, unless the underlying platform already does it.
Here are some possible steps a site could take, all relatively low-hanging fruit:
Place all content within HTML5 semantic container tags, specifically article, aside ,nav, section, figure, figcaption, footer, header, and main
Assign ARIA landmark roles to content containers and HTML headings
Assign aria-labelledby and aria-describedby attributes to appropriate content containers
Set the title attribute for content containers (less desirable, since it's seen by all)
Which of those are worth doing? Taken together, would they make a real difference in accessibility for people with disabilities? Are there other simple things that improve accessibility?
(I'm specifically not talking about forms or interactivity, that's a whole other topic. I'm also not talking about making sure HTML and image colors have good contrast, not because it's unimportant, but because that has to be done on a case-by-case basic, rather than in global templates.)
You'll get the biggest accessibility impact focusing on strong keyboard navigation and thoughtful DOM structure including clear heading outline and semantic sectioning with HTML and ARIA. Keyboard navigation is the primary mode of navigation for screen reader users and many folks with mobility impairments, so a foundation there is a prerequisite to any actions or workflows in your site.
Do use HTML5 sectioning elements. Besides making your markup and CSS rules more elegant, it defines the page structure more clearly to screen readers and makes page navigation easier. The semantics of many elements are already supported - albeit inconsistently - in NVDA, JAWS and VoiceOver.
ARIA landmarks also have good support in these 3 screen readers, in particular as a way to skip redundant header content. Use role='main' on the containing element for your primary content.
aria-describedby and aria-labelledby are useful for complex forms and modals. Before relying on these attributes though, focus on creating coherent read order and clearly labeling and grouping form elements. Specifically, use the for attribute to associate <label>s with their controls, and use <fieldset>s with <legend> to group related controls.
Avoid using the title attribute in general. There is no way to display its content via keyboard focus so it is effectively useless for keyboard-only users who do not use screen readers, not to mention mobile devices.
Depending on the scope of your content, you'll need to go further than these recommendations for robust accessibility, but you've got the right idea in trying to address low hanging fruit first. It will go a long way.
By tagging this with section508*, it tells me the site you are making is for the US Federal Government, or a state that adopted the Standards. Section 508 has outlined Standards to be considered accessible to people with disabilities. Some agencies have developed their own checklist, which either extends the Standards, mimics them; such as HHS' checklists. I recommend you getting with the agency Section 508 Coordinator to see what they do for determining 508 compliance. However, if you are wanting your product to be used by a government agenncy, I recommend filling out a VPAT for it.
If you are wanting to build accessible sites, in general, I suggest following WCAG 2.0
Is applying ARIA landmark roles alone a major accessibility improvement, or a half-measure that doesn't accomplish very much?
ARIA helps accessibility somewhat. ARIA let's you mark certain areas of a page as hotspots per say. I suggest you look at my answers in accessibility or mine about ARIA
Are there other relatively easy things a site can do to significantly improve accessibility?
There are things that are pretty easy, I suggest checking out the links I posted above for a starting point, then ask questions regarding on implementation. WebAIM also has some resources on accessibility.
From comments
I'm looking for actions a site can take that will be of real practical benefit to users, even if they can't go as far as what Section 508 requires
I would recommend not moving forward with this mindset. All of the provisions of Section 508 or guidelines of WCAG have practical benefit, the question is which apply to your site/application. For example, if you have a table with one header row, and/or one column of headers, provision (g), would be applicable:
(g) Row and column headers shall be identified for data tables.
However, if you have a more complex table (g) would not be applicable, instead (h) would be:
(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
However in WCAG, there is no such guideline for tables, it is tucked under 1.3.1, info and relationships and detailed in WCAG 2.0 Technique H51. I can make the same argument for every provision of 508, or guideline of WCAG 2.0.
Headings are by far the most used in-page navigation, most reader users are now aware or ARIA landmarks but usage habits are quite varied.
Yes HTML headings are the most widely used navigation method around because they have been around since HTML 2.0 (Nov 1995). However they are only a navigational option for people who use screen readers, and people who use the Opera web browser. There is probably an add-on for Firefox, but didn't look it up. If you are going to be implementing headings in your site/app (which I recommend), be conscious about what headings you use. They should form a hierarchy of sorts, so don't jump from a <h1> to an <h4> because the look of the font; instead, use an <h2>, and restyle with CSS.
This also is the same for ARIA. ARIA navigation is only available for JAWS, NVDA, and I believe WindowEyes, but for all other assistive technology, nope. There is an add-on for Firefox for basic navigation of ARIA Landmarks(personally I don't like it). However, until browsers implement a built-in way to navigate ARIA landmarks, you cannot just pop them in and say your site is now fully accessible.
*- keeping the part about Section 508 in for reference since the question was originally tagged with it.
A couple of simple but effective steps:
Ensure non-mouse users can see which element is in focus. Many CSS reset styles remove the browser defaults. A dotted line is better than colour
button:focus {
outline: dotted 1px #000;
}
a:focus {
outline: dotted 1px #000;
}
But if colour is used it should meet colour contrast requirements. Check out https://addons.mozilla.org/en-us/firefox/addon/juicy-studio-accessibility-too/
Put a "skip to main context link" as the first tab item on the page. Have a look at http://www.anz.com.au for a great example. Just tab into it.
It's important to note that screen reader users can navigate just using the headers (H1, H2 etc) so this is particularly important. Also note that they also use the down arrow to navigate content and tab for when they get to a form or form element.
Hope this is helpful.
Reduce the amount of clicks it takes to get somewhere, which also goes hand-in-hand with making sure that the most used features on the site are easily accessible from your main page. Also, make sure those same "vital" uses of your site are easily found on every page in the entire site.
You may think it's easy to just click home, and then access the vitals from there, but users tend to really dislike this architecture. Although, that is for main-stream, common users. If you're catering to a certain type of user, then the entire architecture needs to be tweaked.
Analytics are key... Good luck!
I'm looking for best-practices for designing a site that with accessibility in mind. The site is going to have a lot of older and less-abled individuals visiting it, and I want to make it as friendly for them as possible. Is there a resource that describes all the right tags, and attributes to use?
There are many many resources depending on your goals.
Strongly suggest you start with:
Section 508 (US legislation, obviously US centric though)
W3C's Web Accessibility Initiative and Web Content Accessibility Guidelines
edit:
Forgot to mention that WCAG has come in for some considerable criticism which makes this guy's efforts very helpful.
Also wanted to add, from personal experience, to remember that WA doesn't mean "blind people with screen readers". There are all manner of access limitations which you have to think of as well: e.g. dexterity issues related to e.g. muscle control, unusual input devices, and simple screen magnification.
Good luck!
Here's a quick list I tend to follow
Ensure it uses clean XHTML markup ideally to AAA standards,
Try where possible to spilt HTML, CSS, Javascript into respective files,
Create different style sheets for print, screen, etc.,
Ensure you take into consideration colours and fonts for the hard of sight and colour blindness,
Try to only place the main navigation at the top of the code so that the actual content appears near the top of the code, this way people do not have to scroll to far to see the content especially if they are using a screen reader / low res,
If you do have a lot of navigation before the content then place a link near the top allowing users to skip to the content,
Ensure the very first link on the page is to a text-only / low graphics version of the site,
Ensure ALL pages and all Essential functionality will work without JavaScript turned on,
There are lots of plugins for firefox to assist with development including:
Web Developer
No Script
HTML Validator
Firebug
Ensure the page renders across all browsers including old ones even if that means it works though does not match design exactly.
Ensure HTML, CSS, JavaScript is kept to the minimum file size to aid downloading times e.g. Remove white space and blank lines,
Always use LABELS in forms and alt, title tags in links and images,
Only use Tables for tabular data and ensure data appropriately labelled,
Where possible do not use JavaScript to write content to a page but use CSS to hide it, that way is JavaScript is disabled or does not work properly then content will still appear,
Always ensure you use onkeypress as well as onclick events in JavaScript encase the user can not / is not using a mouse.
Finally if you have to use blank images on a page for tracking etc. then don't give them Alt tags. This is my own view and is one which is hotly debated on-line especially when 1x1px images used to be used for spacing. However as far as I see it, if you are using a screen reader then you don't what it reading out stupid comments for images it does not need to see.
Try looking at Wikipedia's article on Web Accessibility. It contains lots of links to various sources of information for different countries, which may be useful depending on your target audience. The W3C was one of the original standards, but has plenty of critics.
Among other things.. provide "alt" and "title" attributes for every "img" tag.
Get a text-only browser like lynx. If your site works in lynx, it's likely to work for people who need screen readers or have other handicaps. It's no substitute for looking up the regulations, but it's a quick and easy check.
For another perspective, see the Dutch Government Web Guidelines.
The government provides a standard called section 508 that lays out what makes a site compatible.
A good resource is found at W3C site: Web Content Accessibility Guidelines.
A few things to keep in mind:
have a CSS link on each page that easily allows the font size to be changed.
Visually try to have appropriate presentation that is easy to read in a backwards S fashion.. left to right, back down.. etc..
ensuring that all the alt tags, etc, as mentioned in the other responses is vital.
see if there are some disability websites out there that specialize in testing your site. no harm in seeing what they list as being important to do.
make sure things are easy to read and find. this alone will make the job much easier.
There are many many resources on this topic. In fact, the danger is of information overload, rather than not enough information.
But an alternative approach is to think about your HTML page in generic terms, rather than the visual output you see in the web browser. If you wrote a piece of software that interpreted the website what would be helpful? This is a round-about way of saying use good semantics. My top tips would be to use standard XHTML for content and CSS for design. Also look up topics such as "progressive enhancement" and "behavioral Javascript".
But for resources:
The W3C's Web Accessibility Initiative: www.w3.org/wai
www.WebAIM.org
www.Accessify.com
www.CSSZenGarden.com for inspiration on how semantic markup can be styled to look very different.
It hasn't been mentioned yet so I figure I would mention it. If you want blind users to be able to use your site avoid flash. At the most 1% of flash I find on the internet is accessible.
A good list of resources about accessibility (colourblind screen-reader,typography etc) is here in design way.
For validation of web site and general documentation I use the W3C.
If you're developing in asp.net the opensource NAAK tool might be useful.
A must read is Jeffery Zeldman's "Designing with Web Standards"
Not sure if you are using Dreamweaver, but he has also just realeased a toolkit to validate your site for accessiblity.
It seems like every time I try to create a pure CSS layout it takes me much longer than if I'd use a table or two. Getting three columns to be equal lengths with different amounts of data seems to require particular fancy hacks, especially when dealing with cross-browser issues.
My Question:
Who are these few tables going to hurt?
Tables seem to work particularly well on tabular data — why are they so reviled in this day and age?
Google.com has a table in its source code, so do many other sites (stackoverflow.com does not by the way).
Since this is stackoverflow, I'll give you my programmer's answer
semantics 101
First take a look at this code and think about what's wrong here...
class car {
int wheels = 4;
string engine;
}
car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;
The problem, of course, is that a bike is not a car. The car class is an inappropriate class for the bike instance. The code is error-free, but is semantically incorrect. It reflects poorly on the programmer.
semantics 102
Now apply this to document markup. If your document needs to present tabular data, then the appropriate tag would be <table>. If you place navigation into a table however, then you're misusing the intended purpose of the <table> element. In the second case, you're not presenting tabular data -- you're (mis)using the <table> element to achieve a presentational goal.
conclusion
Whom does this hurt? No one. Who benefits if you use semantic markup? You -- and your professional reputation. Now go and do the right thing.
Like a lot of things, it's a good idea that often gets carried too far. I like a div+css driven layout because it's usually quite easy to change the appearance, even drastically, just through the stylesheet. It's also nice to be friendly to lower-level browsers, screen readers, etc. But like most decisions in programming, the purpose of the site and the cost of development should be considered in making a decision. Neither side is the right way to go 100% of the time.
BTW, I think everyone agrees that tables should be used for tabular data.
In the real world, your chances of taking one design and totally reskinning it without touching the markup are pretty remote. It's fine for blogs and concocted demos like the csszengarden, but it's a bogus benefit on any site with a moderately complex design, really. Using a CMS is far more important.
DIVs plus CSS != semantic, either. Good HTML is well worthwhile for SEO and accessibility always, whether tables or CSS are used for layout. You get really efficient, fast web designs by combining really simple tables with some good CSS.
Table layouts can be more accessible than CSS layouts, and the reverse is also true - it depends TOTALLY on the source order of the content, and just because you avoided tables does not mean users with screen readers will automatically have a good time on your site. Layout tables are irrelevant to screen reader access provided the content makes sense when linearised, exactly the same as if you do CSS layout. Data tables are different; they are really hard to mark up properly and even then the users of screen reader software generally don't know the commands they need to use to understand the data.
Rather than agonising over using a few layout tables, you should worry that heading tags and alt text are used properly, and that form labels are properly assigned. Then you'll have a pretty good stab at real world accessibility.
This from several years experience running user testing for web accessibility, specialising in accessible site design, and from consulting for Cahoot, an online bank, on this topic for a year.
So my answer to the poster is no, there is no business reason to prefer CSS over tables. It's more elegant, more satisfying and more correct, but you as the person building it and the person that has to maintain it after you are the only two people in the world who give a rat's ass whether it's CSS or tables.
Using semantic HTML design is one of those things where you don't know what you're missing unless you make a practice of it. I've worked on several sites where the site was restyled after the fact with little or no impact to the server-side code.
Restyling sites is a very common request, something that I've noticed more now that I'm able to say "yes" to instead of try to talk my way out of.
And, once you've learned to work with the page layout system, it's usually no harder than table based layout.
I'm of the thought that CSS layout with as few tables as possible is cleaner and better, but I agree that sometimes you just gotta use a table.
Business-wise, it's generally "what's going to get it done the fastest and most reliable way." In my experience, using a few tables generally falls into that category.
I have found that a very effective way to mitigate cross-browser differences in CSS rendering is to use the "strict" doctype at the top of your page:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Also, for the dreaded IE6 CSS issues, you can use this hack:
.someClass {
background-color:black; /*this is for most browsers*/
_background-color:white; /*this is for IE6 only - all others will ignore it*/
}
The main reason why we changed our web pages to DIV/CSS based layout was the delay in rendering table based pages.
We have a public web site, with most of its users base is in countries like India, where the internet bandwidth is still an issue (its getting improved day by day, but still not on par). In such circumstances, when we used table based layout, users had to stare at a blank page for considerably long time. Then the entire page will get displayed as a whole in a tick. By converting our pages to DIV, we managed to bring some contents to the browser almost instantly as users entered to our web site, and those contents where enough to get the users engaged till browser downloads entire contents of the page.
The major flaw with table based implementation is that, the browser we will show the content of the table only after it downloads the entire html for that table. The issue will blow out when we have a main table which wraps the entire content of the page, and when we have lots of nested tables. For the 'flexible tables' (those without any fixed width), after downloading entire table tag, browser has to parse till the last row of the table to find out the width of each columns, then has to parse it again for displaying the content. Till all these happens users has to stare at a blank screen, then everything will come to screen in a tick.
If you have a public facing website, the real business case is SEO.
Accessibility is important and maintaining semantic (X)HTML is much easier than maintaining table layouts, but that #1 spot on Google will bring home the bacon.
For example: Monthly web report: 127 million page views for July
Monthly web report: 127 million page views for July
...
Latimes.com keeps getting better at SEO (search engine optimization), which means our stories are ranking higher in Google and other search engines. We are also performing better on sites like Digg.com. All that adds up to more exposure and more readership than ever before.
If you look at their site, they've got a pretty decent CSS layout going.
Generally, you find relatively few table layouts performing well in the SERPs these days.
Keep your layout and your content separate allows you to redesign or make tweaks and changes to your site easily. It may take a bit longer up front, but the longest phase of software development is maintenance. A css friendly site with clear separation between content and design is best over the course of maintenance.
One other thing I just remembered, you can assign a different stylesheet to a page for printing vs. display.
In addition to your normal stylesheet definition, you can add the following tag
<link rel="stylesheet" type="text/css" media="print" href="PrintStyle.css" />
Which will render the document according to that style when you send it to the printer. This allows you to strip out the background images, additional header/footer information and just print the raw information without creating a separate module.
doing a complete revamp of a 15 page web site just by updating 1 file is heaven.
This is true. Unfortunately, having one CSS file used by 15,000 complex and widely differing pages is your worst nightmare come true. Change something - did it break a thousand pages? Who knows?
CSS is a double-edged sword on big sites like ours.
In my experience, the only time this really adds business value is when there is a need for 100% support for accessibility. When you have users who are visually impaired and/or use screenreaders to view your site, you need to make sure that your site is compliant to accessibility standards.
Users that use screenreaders will tend to have their own high-contrast, large-font stylesheet (if your site doesn't supply one itself) which makes it easy for screenreaders to parse the page.
When a screenreader reads a page and sees a table, it'll tell the user it's a table. Hence, if you use a table for layout, it gets very confusing because the user doesn't know that the content of the table is actually the article instead of some other tabular data. A menu should be a list or a collection of divs, not a table with menu items, again that's confusing. You should make sure that you use blockquotes, alt-tags title attributes, etc to make it more readable.
If you make your design CSS-driven, then your entire look and feel can be stripped away and replaced with a raw view which is very readable to those users. If you have inline styles, table-based layouts, etc, then you're making it harder for those users to parse your content.
While I do feel that maintenance is made easier for some things when your site is purely laid out with CSS, I don't think it's the case for all kinds of maintenance -- especially when you're dealing with cross-browser CSS, which can obviously be a nightmare.
In short, your page should describe its make-up in a standards compliant way if you want it to be accessible to said users. If you have no need/requirement and likely won't need it in the future, then don't bother wasting too much time attempting to be a CSS purist :) Use the mixture of style and layout techniques that suits you and makes your job easier.
Cheers!
[EDIT - added strikethrough to wrong or misleading parts of this answer - see comments]
The idea is that Designers can Design and Web Developers can implement. This is especially the case in dynamic web applications where you do not want your Designers to mess around in your Source Code.
Now, while there are templating engines, Designers apparantly just love to go crazy and CSS allows to pull a lot more stunts than tables.
That being said: As a developer, i abandoned CSS Layout mostly because my Design sucks anyway, so at least it can suck properly :-) But if I would ever hire a Designer, I would let him use whatever his WYSIWYG Editor spits out.
Business reason for CSS layout: You can blow away the customers by saying "our portal is totally customizable/skinnable without writing code!"
Then again, I don't see any evil in designing block elements with tables. By block elements I mean where it doesn't make any sense to break apart the said element in different designs.
So, tabular data would best be presented with tables, of course. Designing major building blocks (such as a menu bar, news ticker, etc.) within their own tables should be OK as well. Just don't rely on tables for the overall page layout and you'll be fine, methinks.
*I would let him use whatever his WYSIWYG Editor spits out
I just threw-up a little...
*ahh hello? You don't think the graphic designer is writing the CSS by hand do you?
Funnily enough I have worked with a few designers and the best among them do hand-tweak their css. The guy I am thinking of actually does all of his design work as an XHTML file with a couple of CSS files and creates graphical elements on the fly as he needs them. He uses Dreamweaver but only really as a navigation tool. (I learned a lot from that guy)
Once you've made an investment to learn purely CSS-based design and have had a little experience (found out where IE sucks [to be fair it's getting better]) it ends up being faster I've found. I worked on Content Management Systems and the application rarely had to change for the designers to come up with a radically different look.
Besides being easily updatable and compliant...
I use to design all table based web sites and I was resistant at first, but little by little I moved to CSS. It did not happen overnight, but it happened and it is something you should do as well.
There have been some nights I wanted to toss my computer out the window because the style I was applying to a div was not doing what I want, but you learn from those obstacles.
As for a business, once you get to designing web sites by CSS down to a science, you can develop processes for each site and even use past web sites and just add a different header graphic, color, etc.
Also, be sure to embed/include all reusable parts of your website: header, sub-header, footer.
Once you get over the hump, it will be all down hill from there. Good luck!
:: nods at palmsey and Jon Galloway ::
I agree with the maintainability factor. It does take me a bit longer to get my initial layouts done (since I'm still a jedi apprentice in the CSS arts) but doing a complete revamp of a 15 page web site just by updating 1 file is heaven.
Some additional reasons why this is good practice:
Accessibility - the web should ideally be
accessible by all
Performance - save
bandwidth and load faster on mobile
devices (these lack bandwidth to some
degree and cannot layout complex
tables quickly). Besides loading fast is always a good thing...
When a screenreader reads a page and sees a table, it'll tell the user it's a table. Hence, if you use a table for layout, it gets very confusing because the user doesn't know that the content of the table is actually the article instead of some other tabular data
This is actually not true; screen readers like JAWS, Window Eyes and HAL ignore layout tables. They work really well at dealing with the real web.
I don't think there is a business reason at all. Technical reason, maybe, even so, barely - it is a huge timesuck the world over, and then you look at it in IE and break down and weep.
i actually can see Tables in Stack Overflow on the user page.
It even has heaps of inline styles...
There definitely is. If you are still striving for it, you are not getting it right.
DIV+CSS layout is actually much easier than table layout in terms of maintainability and productivity. Just keep practicing it before it's too early to say that.
Table layout is good too it's just not meant for layouts and have exceptional drawbacks when it comes to minor tuning.