Related
I am looking for a way to mark some text as WCAG compliant or somehow otherwise exclude it from automated accessibility tests.
Quite often WCAG requirements state that certain criterion has to be met unless there's a good enough reason otherwise. In my case it is a placeholder text in a search input field. The field has an accessible label below it. The placeholder text is not functional and is added purely for decorative purposes as it is currently the standard in the web design industry to have it. As the text bears no functional purpose - the contrast WCAG requirement doesn't need to be met. Indeed, having the placeholder text with quite low contrast is required - if it is too dark it would appear as if there is already some input in the input field.
However, whenever I run an automatic check it (reasonably so) picks up the placeholder text as a colour contrast problem. That creates a business issue - as getting no warnings at the automatic tests is one of the client's accessibility requirements.
Android apps seem to have a flag like "IMPORTANT_FOR_ACCESSIBILITY_NO ", which would have been sufficient for this issue. Is there some equivalent for JavaScript Web Apps?
Short answer - no, there is no way to hide placeholder text from accessibility checkers without hiding the whole field (aria-hidden="true") which is not an acceptable route as you can imagine.
The one question you should be asking is why have placeholder text at all if it offers no purpose other than decoration? (can you not make the form more presentable another way)
Either make it high enough contrast (#767676 on white is 4.5:1) and italic (the only time italics are suitable from an accessibility perspective) or get rid of it entirely.
If you have correct associated labels with each input field then placeholder text should only be used to convey extra information such as formatting (e.g. enter date in format DD/MM/YYYY).
Side Note - if you do add extra information to a field via the placeholder, such as how to format a date, then make sure you also add the information to the label and use a 'visually hidden' class to hide the content of that text as screen readers often ignore placeholder text and the information is useful to none sighted users.
Think of it this way:-
John has low contrast perception problems (the point of contrast of 4.5:1).
John encounters your form on a website and can see some really feint text.
John strains his eyes only to realise the text offers no useful information.
You have now added 1 minor annoyance to your site that could reduce sales conversions for clients like John. (I know it is only minor but our goal is to remove barriers to a sale / enquiry at every stage.)
Worse yet, if John cannot make out the text at all he may think it conveys important information and be uncertain as to what he needs to enter, causing him to abandon your form entirely.
I work on a multilingual website that will contain many languages that are not normally written, and I wonder if there are any ways to get this working for people using screen readers? Is it possible to give a text an attribute to make the screen reader play a prerecorded sound instead of trying to read the text by itself?
The whole menu system will be translated into the languages that are not supported by any screen readers.
The two popular screen readers are JAWS and NVDA. You can see what languages JAWS supports, 28 in total. NVDA supports 43 languages (I couldn't find a list).
I wonder if there are any ways to get this working for people using screen readers
There is a few things you could do that come to mind:
Declare the language of the page via the <body lang="">, so that if the screen reader happens to know how to interpret it, it uses that language
Put links to common language translations near the top of the page so if somebody lands on a random page from a search engine hit, they can change languages quickly.
Is it possible to give a text an attribute to make the screen reader play a prerecorded sound instead of trying to read the text by itself?
The lang attribute makes the screen reader switch to another language if it understands it. You can provide links to audio files to be listened to, I would be a little cautious with providing your own audio player. Not all audio players are accessible, the two common issues with these are the controls are not labeled and they cause focus trap.
Unlabeled controls make the assistive technology say "unlabeled" or something similar, so you cannot tell the buttons apart from each other. Focus trap effects people who use the keyboard to navigate a page, this is usually using the Tab key, and instead of getting out of the audio player, it goes to the first element of the audio player again.
From Comments
How I can make the screen reader play these files instead of trying to read the text.
The only thing you can do is use ARIA to hide the content via the aria-hidden='true' attribute. You can check my answer about aria-hidden for more details. Essentially you would do something like:
<article aria-hidden="true">
<h1>Some Really cool language</h1>
<p>Blah blah blah</p>
<section aria-hidden="false">
<h2>Audio of language</h2>
<p>below is an audio sample of ____. Blah blah blah</p>
<p class="offScreen"><!-- it may be a good idea to put additional
info for people using assistive tech --></p>
<p>audio stuff</p>
</section>
<article>
CSS
.offScreen{
position: absolute;
top: 0;
left: -999px;
}
Ryan, I've seen this question asked elsewhere about "click" languages, as of southwestern Africa. So far as I know, there is no written alphabet that is intrinsic to these languages. Scholars might record the languages phonetically, but more common techniques involve adding exclamation points and perhaps other basic keyboard characters to indicate the vocalizations that cannot be conveyed by European alphabets. The Kx'a family of languages is one such group.
If you look for RFC 1766 on sourceforge.net, you'll find a list of 122 languages or variants of languages that map to specific values of the lang attribute. And RFC 1766 itself shows how to add Klingon and other "experimental" languages to the mix.
So there are several issues, it seems:
If a language has not yet been mapped, how does one create a mapping of its characters and groups of characters (its graphemes) to its sounds (its phonemes)?
Assuming that's all that is required, how does one get that mapping associated with a new value for the lang attribute? (To get that new value, RFC 1766 says to create, complete, and submit a simple form. But, given that the document called RFC 1766 is 18 years old, how reliable is that information? And just where does the mapping of symbols to sounds fit into the picture?)
Ultimately, how does one get a screen reader to recognize that mapping and the corresponding value of the lang attribute?
My somewhat contrarian take: don't try to automatically replace the text with pre-recoreded content; instead focus on ensuring that the user is aware that both are available, and can access whichever is most appropriate for them based on the tools they have at their disposal.
Some more background context might help: from your description, it sounds like this is perhaps an academic or research site, that has fragments of text in these languages, with audio; but where the remainder of the site structure - headings and supporting narrative text - is in some 'well-supported' language (English, etc.)? (What is the encoding system used for this test?)
If so...
Be aware that a screenreader user does not typically read an entire page top-to-bottom in a completely linear fashion; they can browse the page using the heading structure. In a well-marked-up-page, the user has the freedom to skip over the portions that they are not interested in or which are not relevant to them. Focus on providing this flexibility rather than making (well-meaning, but potentially incorrect) policy decisions on behalf of the user.
Don't assume that a screenreader user is using speech in the first place; they could be using Braille, whether due to the fact that speech output is not an option for them, or simply because Braille is their preferred form of output.
Finally, don't assume that because a screenreader user can't hear the text properly (due to text-to-speech limitations), that the textual form of the content should be hidden from them entirely; they may still want the ability to cut-and-paste the characters that represent the text so that they can send them to a colleague, for example. Or, depending on the writing scheme used, a screenreader user may still be able to step through the characters letter-by-letter and have the words spelled out to them letter-by-letter - many screenreaders can call out non-latin characters by their Unicode name.
The issue here is less about JAWS and more about having a Synthesizer which speaks the language and can communicate with JAWS through a driver such as SAPI 5. Development of these languages for the various synthesizer companies can be costly, especially if there is not a good business case driving it such as GPS, ATMs, Call Centers, etc.
There are open source solutions such as eSpeak which you might look into as well. It is not the highest quality but could be an approach if you have access to developers willing to work on such a project.
As for the question regarding an API or method to communicate information to JAWS via prerecorded sound files of the web site? This is not really going to meet the need of the screen reader user who would have no way to navigate the information or interact with it using Links or form field elements. I really think the synthesizer development is the only solution unfortunately.
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...?)
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.