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.
I need to make an email template and make it responsive. As I see that to achieve that you need to use media queries and css styles on a header etc. I was wondering if tables are not needed anymore to set the layout (they are quite annoying anyway).
But I see blogs explaining how to make a responsive HTML email with tables so I wonder why do they use tables if they have CSS?
Is it because it's some type of compatibility approach? So that old systems will still show the layout even if not perfect and new ones will show it better?
Cheers.
Email clients use really old rendering engines. If you opt for using div's instead of tables you will see your email breaking almost everywhere (specially outlook). Using tables allows you to support old email clients as well as making your email responsive for those that support it.
There are a lot of good tutorials out there that give you templates that you can start from, I suggest you use those and build from there. It takes a little while to perfect it across all clients and platforms and the testing ain't no fun!
This tutorial will come in handy.
If you can get a Litmus account it makes the testing less painful and they get it right most of the time.
Also, if you are already doing emails try to study what device/client most of audience uses and you can use that to make sure your new template renders fine on these.
Good luck!
I am creating outlook email. I have created an email system. I have check in all email giants like Gmail, yahoo etc it work perfectly but suddenly when I saw same email in outlook it was shocking that outlook not supports position attribute.
Now, what I want is to achieve same functionality, I have searched on Google but not found a good source to solve issue except this platform to ask question.
Please help!
Thanks in advance.
Note: I don’t want to do this by placing one div inside other. This not suits my application at all i want things to positioned with respect to corners (width/height).
outlook does not support position:, so perhaps use a table-based solution?
check out these links;
http://msdn.microsoft.com/en-us/library/aa338201.aspx
http://www.campaignmonitor.com/css/#css-com_1
Whether you choose to code your HTML email by yourself (my personal preference) or to use an existing template, there are two fundamental concepts to keep in mind when creating HTML email:
Use HTML tables to control the design layout and some presentation.
You may be used to using pure CSS layouts for your web pages, but
that approach just won’t hold up in an email environment.
Use inline CSS to control other presentation elements within your
email, such as background colors and fonts.
Keeping css 1.0 standards in mind will help you a lot when it comes to outlook. For some other details click here. Have fun!
I was just playing around with Firebug and editing Gmail's CSS file, and I wanted to edit a button, but the div ID for that button was :rj. I am fairly certain that CSS does not allow colons in —and especially starting as—ID and class names. So my guess is this is some advanced trickery. I'm not sure if it's consistent like this for each user, but FWIW, the ID was for the "Search Mail" button at the top of the page.
Does anyone know what they are doing and how they are doing it?
IDs used to be quite strict on what was allowed, not so much for classes. HTML5, however, has lessened a lot of the restrictions on what could be ID values.
Here's an article on the what's allowed for IDs and classes in HTML5: http://mathiasbynens.be/notes/html5-id-class
It's enough to make your head hurt.
EDIT:
To address more of your question about why Google is using a seemingly random ID, I'm sure the IDs and classes they are using make perfect sense to their programmers.
Google only owns one browser so if they want to create a web app that is cross browser compatible like firefox they must follow the same standards and rules as every other web developer. That said most modern browsers are pretty lenient when it comes to parsing html so while your example is not correct HTML and probably wouldn't validate there would be no visible negative effects.
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.