Related
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 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.
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.
I have a web application where I would like to allow end users to customise the look of the web site by uploading their own css file.
Are there any security issues with this? I can't see anything obvious but thought I'd ask in case there was anything I'd missed.
Javascript can be executed in CSS, you have to make sure that you are using some filtering.
I have also seen incidents where someone has covered the entire page on a microsoft controlled site with a transparent pixel, linking to a malicious site. Clicking anywhere triggered the attackers site to appear.
This could however be safe if the user only sees his or her own CSS, and they would have no way of someone else viewing what they have done. Otherwise some sort of whitelist or markdown would work.
Short answer: no it isn't. HTC in IE and XBL in Mozilla are both potential attack vectors. A hack of this nature was used to steal 30,000 MySpace passwords a while back.
Source: Simon Willison, Web Security Horror Stories
I wouldn't do it because CSS can show an image that could exploit some OS vulnerability in example.
Regards.
Depending on your server and configurations, it may be possible to run server-side code from a CSS file (though, this isn't default behavior on servers I know).
Short answer: no. First bad things that come to mind are MSIE expressions.
If these CSS files are available to all site users, and not just the person who uploaded, then there's a possible XSRF vector - you could include links to offsite resources in the CSS which perform "undesirable" effects to the user requesting them.
You may get customer support overhead if a user with his custom CSS screws the screen to that extent that he won't find the controls to reset it back. In which case you as admin will need to do it manually.
For that case a possible solution. Arrange for a specific Url to reset the style. Something like:
http://mysite.com/users/234234/reset
And advice to the user when he's about to modify the style to remember this Url and just follow it if things have gone out of control. When hit, the custom styles will be deactivated.
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.