So we should make accessible web sites, providing alt attribute for img elements and all other stuff. But although this effects comparatively lesser number of users, I could not find any information to the issues that effects each and every user.
Let me explain. If we were to simplify matters by saying that web sites should provide the most revelant information in the least amount of time, would I be wrong? Given this axion if I were to
1 - Want to download the offline version of Acrobat Reader X. There is nothing, and I mean nothing on the site http://www.adobe.com/products/reader.html which provides a hint, link or anything to that. I have to use google to find ftp://ftp.adobe.com/pub/adobe/reader/
2 - Again trying to find the offline version of Google Chrome at http://www.google.com/chrome/ . Nothing there that may lead to http://www.google.com/chrome/eula.html?standalone=1
3 - So Internet Explorer has an addon called Web Developer Tool Bar. It is safe to assume I will find it at http://www.ieaddons.com/in/. No such luck. Have to google it again and find it at http://www.microsoft.com/downloads/en/details.aspx?FamilyID=95e06cbe-4940-4218-b75d-b8856fced535
4 - Trying to get the the Firebug addon from https://addons.mozilla.org/en-US/firefox/extensions/web-development/. Successfully navigated to web development. You can use "view all recetally added" or "view all top downloads" or "view all top rated". What if you want to view all for web development. Offcouse you sue the search!
These are just some of the situations. I guess my question would be that are these not accessibility issues?
If the issues you are are describing apply equally to say sighted users as to blind users using a screenreader, then no, they are not considered to be accessibility issues, but are perhaps broader usability issues.
If, for example, the adobe web site had no link at all to the offline version, and all users, sighted or not, had to do extra work to find it, that's a usability issue.
But if the web site had a graphic image that sighted users could see was a link to the download, but users using a screenreader did not get this information (eg. because the graphic had no ALT text, or the image was not operable via keyboard), then it's an accessibility issue.
There's certainly overlap between these; and it's often the case that usability issues are harder for disabled users to work around; but generally accessibility refers to cases where the design of a site confronts a user with a disability with additional barriers or challenges beyond those that users without a disability have to deal with.
I think it depends on your definition. Some definitions describe accessibility assuming that the correct website is known and is concerned only with the accessibility of that website. Others do describe the ease of users finding the required resource on the Web, which would encapsulate your issues above.
There are two reasons why accessibility is a failure on the web, and for these failures the technology HTML is to blame for both.
1) HTML is not self-validating. SGML does not have a direct self-validating subset and all versions of HTML < 5 are subsets of SGML. HTML5 is based upon a specification document not vested in any computer language, so its perhaps more lost.
XML does have a direct self-validating subset called schema. There are three widely recognized schema languages for XML: Schematron, Relax NG, W3C XML Schema (official).
By self-validating I mean that the language itself can be called to validate its instances without external assistance from the local parser. Without a self-validating component there is no assurance of integrity of a document's structure, and therefore there is no integrity of accessibility. In a world where web browsers will parse anything without regard for the proper well-formedness of a structure then by practice everything is acceptable completely without regard for accessibility.
2) Less obvious and more devastating is that HTML does not understand its own structure. There are two levels of structure as defined in the HTML specifications: block-level elements and inline elements. According to the specifications the difference between these two structure levels is vested primarily in the visual intention of the elements' presentation, which contradicts other language in the specifications in that HTML is a data structure and not a presentational language.
Furthermore, two levels of structure is insufficient and the actual structural definition of HTML elements exceeds a two level structure anyways without inherently stating such. For example in HTML many block-level elements may contain a 'p' element representing a paragraph, but such an element may not contain other block level elements although many other block level elements may certainly contain block level children.
At a minimum a three level structure is required to describe natural language in a manner consumable to a human audience equally without need for further accessibility assistance. In accordance with the structure defined in Mail Markup Language there would be:
Complex blocks
Simple blocks
Inline elements
Complex blocks are purely structural in that they may contain simple blocks, or in some cases other complex block elements, but will never contain inline elements or text nodes. Simple blocks will never contain complex block or simple block elements, but may contain inline elements or text nodes. Inline elements be either singletons containing nothing or will contain text nodes, but inline elements will never contain other elements.
Such a structure is self-sufficient in properly arranging and structuring content so that accessibility requirements are met immediately in a manner where violations of accessibility requirements are more costly and complex than simple conformance to the given structure. Once a sufficient structure is in place all that is missing is the meta data supplied via descriptive and well-known element names, and in some cases additional extraneous content via attributes.
If either of these two items are missing a minimum baseline for accessibility cannot be assured. When they are both missing, as with the web, then accessibility is likely a lost cause and immediate failure.
Web accessibility
Website is made up of different contents like images, texts, videos, button, etc, with combination of different colors.
Web accessibility means that people with disabilities can use the Web.
Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.
Web accessibility also benefits others, including older people with changing abilities due to aging.
The main theme of web accessibility is creating a website which is accessible to every one. After designing a website it is essential to check the website ADA compliance, whether it is accessible and how much it is user friendly for disabled people.
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.
Many developers/accessibility experts suggest to disable CSS for checking the website for accessibility, but no one explicitly says how it may actually be helpful in terms of web accessibility.
So here I am, asking you exactly that, because all my attempts to check this in reliable (I WANT TO BELIEVE!) sources like "w3.org", including their WCAG 2.0 recommendations, don't say anything about making website accessible without CSS. Moreover, they say it may be "relied upon" some technology, like CSS, for example.
You no longer need to explicitly verify that pages are readable without CSS, but it can be useful as a technique for ensuring correct reading order.
The requirement to make pages readable without CSS is a carryover from the days when Section 508 was the dominant accessibility standard.
36 CFR Parts 1193 and 1194 - Published February 18, 2017
There is no direct analogy in the WCAG 2.0 Success Criteria for section 1194.22(d) of the existing 508 Standards, which states: “documents shall be organized so they are readable without requiring an associated style sheet.” 36 CFR §1194.22(d).
https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/single-file-version
WCAG 2.0 addresses this same issue in a different way with Success Criterion 1.3.2 - Meaningful Sequence.
One of the techniques for meeting this criterion is making the DOM order match the visual order (C27), which is largely what this comes down to anyway.
I would say that a good reason to actually disable CSS in terms of checking accessibility is to see that your site structure is built up in a logical way.
On the other hand, a better way to test this is to use a screenreader and tab through the site using use tab / shift + tab with a keyboard. In that way you do not only get an eureka-moment on structural issues you also get the audio-feedback that will give you lots of AHA:s about phrasing, ARIA-issues and hidden elements not hidden in a accessible way.
I'd point you to try out ChromeVox
If you use the accessibility testing tool Wave you can actually disable styles in the tool. So, as built in a testing tool it's a great way to test the structural element flow. There is no purpose in itself to disable CSS besides testing accessibility in this way.
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!
How can I ensure (or try to make) web access available for all - who may have a variety of disabiltes?
Any advice for any standards or web sites that could give me some pragmatic advice for the design of a site?
There are a number of considerations you need to address here, if your website isn't catering for a specific disability then you have to work on a broad range of features. In this situation the first thing you need to remember is that you sadly can't cater to everyone. Look at the list below and identify which of these disabilities you can sensibly cater for
Visual: Visual impairments including blindness, various common types
of low vision and poor eyesight, various types of color blindness;
Motor/Mobility: e.g. difficulty or inability to use the hands,
including tremors, muscle slowness, loss of fine muscle control, etc.,
due to conditions such as Parkinson's Disease, muscular dystrophy,
cerebral palsy, stroke;
Auditory: Deafness or hearing impairments,
including individuals who are hard of hearing;
Seizures: Photoepileptic seizures caused by visual strobe or flashing effects.
Cognitive/Intellectual: Developmental disabilities, learning
disabilities (dyslexia, dyscalculia, etc.), and cognitive disabilities
of various origins, affecting memory, attention, developmental
"maturity," problem-solving and logic skills, etc.
The easiest here is the Seizures, eliminate flashing / strobing content from your site, or more importantly if you cant put up a warning before displaying this type of content.
Users with Motor / Mobility issues may have problems interacting with content on your site that requires a high amount of precision, this can be helped by increasing the size of your UI elements, or allowing the user to resize these elements if needed.
Generally make anything clickable as large as is feasible and if you have elements that have features such as drag drop, make the drag handles large so the user doesn't have to click a tiny area.
Auditory is also a fairly easy consideration to make, at the least simply provide text alternatives to any media content your site may have, for larger sites using video then considerations such as sign language may be an option.
Visual is probably the most common consideration web developers need to make. Firstly partially sighted users may want to increase the text size to your page, so make sure that your UI can cope with this. Use clear and readable fonts and make sure there is contrast between the background color and the font color.
Color blind users may wish to change your site color scheme to meet their needs, you can find information easily on the types of color blindness and develop a couple of alternative CSS styles to meet these needs. Also a high contrast option for everything on your site may benefit partially sighted users.
Cognitive / Intellectual is one of the harder considerations to meet, so look at the individual disabilities. ADD for instance makes it hard for a person to focus and makes them easily distracted, considering this think about advertisements, they are designed to distract us and draw our attention, thus by limiting advertisements on your site you can get rid of the ones that flash and scream Click ME!.
Dyslexic users may struggle with reading huge chunks of text which also fits in with considerations for partially sighted people, here you could have an audio option so the text is read aloud to the user.
One more consideration here is the use of color in your website. It has been proven that certain colors can stimulate emotions, for someone with emotional or developmental issues using colors that are considered calming vs ones that excite (reds for example) may improve their experience of your website.
All of the above are design considerations, looking at the development (Code) next there isn't too much you can do, most of the considerations about your code are because of third party applications interacting with your site.
Generally make sure your code is well formed, correct tags / closing tags etc. Make sure it is valid HTML / XHTML / CSS etc if you can validate to the strict standards it wont hurt your cause. Tags such as links / images should have appropriate Alt text to describe what the element is, for instance alt="image1" is fairly useless to a screen reader but alt="Image showing ...... clicking this will take you to....." is useful.
If you can find some trial software grab yourself a screen reader, load up your website, close your eyes and try interact with it, its going to be hard but at least you can see how your user will interact with your site and more importantly you can use the screen reader to check your site actually gets read the way it should.
There are plenty of 3rd party plugins you can integrate with your site to aid your users too, so look into those, things like the option to magnify text or read aloud with just a click will be well received as long as they are not too intrusive to your non disabled users.
Helpful links
http://www.w3.org/TR/WCAG10/ The W3C Disability guidelines are a good place to start
http://en.wikipedia.org/wiki/Web_accessibility Wikipedia web accessability
http://www.etre.com/tools/colourblindsimulator/ Allows you to see how images will appear to colourblind users
http://colorfilter.wickline.org/
http://www.w3.org/WAI/ W3C Web Accessability Initiative Guidelines
Section 508 is the section of the law that requires that US government websites be accessible.
More information is here, including best practices on making content accessible to all.
http://www.section508.gov/
Generally you should support screen readers by using semantic markup, and avoid flashy content and audio -- these are usually impossible or just difficult to make accessible.
You should also look at web typography guidelines and look to hiring a good designer. Poor color schemes, typefaces, and font sizes make reading on the web much harder than it needs to be.
If you're from the UK, from a legal POV you want to be looking at the Equality Act (which replaced the Disability Discrimination Act).
The foundation of web accessibility is based on the graceful degradation/progessive enhancement model (sounds more complicated than it is!). A List Apart wrote a great article on it some time ago.
A good starting point for web professionals is the RNIB's Web Access Centre. Obviously this mainly deals with those user who experience visual disability, but it's a very useful resource.
Web AIM is also a good site for resources/articles although I'm not sure how often it's maintained these days (still, the information there is relevant).
There are far too many individual little things to bear in mind when developing accessible interfaces, but if you take the time to read some of the articles on those sites, you'll pick up the fundamentals which will then lead you onto the more nitty-gritty things.
Accessible development is about a change in mindset as much as learning the nuts and bolts. You need to to be constantly asking yourself "How might other people use this? What barriers might be in their way? What browser are they using? Does this work without colour/JavaScript/CSS?". Learn how to take your site apart and see if it still works.
Web Content Accessibility Guidelines 2.0 (WCAG 2.0) is the W3C Recommendation from Web Accessibility Initiative (W3C/WAI).
An overview can be found here: http://www.w3.org/WAI/intro/wcag20
There are very broad Principles as well as precise Techniques (for HTML, CSS, JS, Flash, etc) and the intent of each and every criteria. These aren't documents meant to be read at once and you'll want to learn more from tutorials and articles found on the web (archives at 456 Berea Street, WebAIM, videos about accessibility)
The W3C Quick Reference guide to WCAG 2 lists all of the relevant techniques you'll need to implement the WCAG2 principles and guidelines that Felipe mentioned, with code examples if appropriate on the individual technique pages. If it's all a bit too technical for you, WebAIM's checklist is the same thing only in plain English.
Unfortunately there's no magic wand for getting sites to be compliant. You have to go through each bit of content and test it and modify it if necessary. Luckily, even some small improvements can make a big difference.
A lot of good answers, but I can't help adding my input as well.
If you want to ensure a website is disabled friendly, there are a number of considerations that should be taken. One that I have not seen on here (perhaps because I skimmed) is to ensure that you use high-contrast colors, with a solid background behind text.
However, you should NOT use white on black or white on black...dyslexics commonly cannot see those colors. Use an off-white for background or text.
Also, make sure your text is large. Ensure as much of the content as possible is standard text, so that text-to-speech programs can "read" the website. Text-to-speech cannot read images. Text links instead of buttons would also be advisable, for the same reasons (though there may be a means of associating text with a button for these scenarios...?)
What are cons if we do not care about validation of XHTML and CSS? Errors other than CSS 3 and vendor specific properties
In terms of development time(How valid XHTML and CSS code save time to find problems?),
Code debugging (How we can track then problem quickly?),
Cross browser compatibility (How it helps us to achieve cross browser compatibility?),
Website maintainability (How it would be helpful to maintain and update for someone else?),
Future changes in website (How it would be helpful to make any changes in design if client can ask in future?),
SEO ranking (How it can affect our site's search engine ranking?)
Accessibility (Does validity of code increase accessibility of site?)
I have to explain a client's Secretary,Code validation is not just Fashion, it is beneficial for his site. I'm not just advocating of this to make more money. it's not useful only for developer it mainly beneficial for his website.
There's the obvious point that if your markup is valid, the odds of it being rendered as you want it to be by a wide variety of browsers are improved.
But separate from that, sometimes you spend valuable development time tracking down bugs (usually ones that seem specific to a given browser) only to find that the reason for the bug is that your markup is invalid and different browsers are handling the invalid markup in different ways. Validating (whether it's XHTML or HTML) saves you time tracking down those sorts of problems. There was an example here just yesterday, in fact. The OP thought he was having a weird Firefox-specific jQuery problem. In fact, he just had invalid markup, and fixing the markup fixed his problem.
So I'm thinking that you tell the client that validation saves time, and therefore money.
Note that this is an argument for validating, not for proclaiming validity (via icons and such).
I found some very good answers here
http://validator.w3.org/docs/why.html
http://ianpouncey.com/weblog/2010/01/web-accessibility-myths/
Using markup improperly -- not
according to specification -- hinders
accessibility. Misusing markup for a
presentation effect (e.g., using a
table for layout or a header to change
the font size) makes it difficult for
users with specialized software to
understand the organization of the
page or to navigate through it.
Furthermore, using presentation markup
rather than structural markup to
convey structure (e.g., constructing
what looks like a table of data with
an HTML PRE element) makes it
difficult to render a page
intelligibly to other devices (refer
to the description of difference
between content, structure, and
presentation).
http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation