Group items tagged

refreshable Braille device which converts the text on the website into Braille.

Place form instructions before the form field

To improve accessibility and usability for screen reader users, form field requirements must be placed before the form field itself.

Provide a ‘skip to main content’ link Screen reader users benefit from a ‘skip to main content’ link as it enables them to jump over lengthy navigation to the main content of the web page, reducing the amount of content they have to listen to.

Ensure link text is descriptive Screen reader users using software such as JAWS can listen to the links on a web page through functionality known as a links list. If link text is not descriptive—solely using phrases such as “click here” or “more information”, for example—there is no way for screen reader users to determine where the link will take them.

Provide descriptive web page titles The first piece of information a screen reader user will listen to when they open a web page is the <title> assigned to the page. It is important, therefore, to use a title which reflects the content of the web page.

Provide descriptive headings It is important to provide descriptive headings

Screen reader users often listen to headings out of context from the main content

Provide audio descriptions and transcripts of video content Screen reader users depend on audio descriptions to provide additional information about important visual content displayed within a video.

Transcripts are written accounts of the video or audio content and can include additional information such as comments and descriptions

screen reader users cannot use a mouse

People with low vision will tend to use magnification software to make reading a website easier. Depending on the severity of their vision impairment, these users may combine magnification and screen reading software by using software products such as Supernova or ZoomText. For milder vision impairments, users may just increase the default size of text within their browser settings or change the colors to make the content more comfortable to read.

Avoid using images of text

Ensure text can be resized

Place key information in specific locations of the screen

ebsite search functionality is often located in the top-right corner of the web page

Juicy Studio color contrast analyzer.

it is possible to determine whether the colors chosen meet the minimum requirements specified in the WCAG Guidelines.

People with a hearing impairment tend not to use assistive software to improve their web browsing experience. Instead, they rely on the website being accessible by providing any audio content in alternative formats, such as captioning or transcripts.

By making audio content accessible for users with a hearing impairment, it also makes the content accessible for other users who find themselves in an environment where audio cannot be heard.

library with the sound turned down; they may be in a noisy environment where it is difficult to hear the audio; or they may be using a computer without speakers.

Provide captions for any video content

Provide transcripts of the spoken audio Where content is spoken without video, such as in a podcast, it is important to provide a transcript. It is recommended that the transcript be provided in plain accessible HTML to allow access by the widest possible audience, as opposed to a Microsoft Word or Adobe PDF document.

Physical disabilities range in severity from those who are temporarily disabled, for example having a broken arm, to those who are quadriplegic and have no use of any limbs. Depending on the severity of the physical disability, these users may access websites through voice recognition software such as Dragon Naturally Speaking.

However, what all users with a physical disability have in common is limited or no ability to use a mouse. This means that content within the website that requires a mouse click or fine motor control cannot be accessed by these users.

Ensure all content can be accessed via the keyboard

Users with a physical disability will have limited or no ability to use a mouse and as such will navigate websites using the keyboard.

Provide a focus state for links

Provide visible skip links Skip links are links that become visible when they receive focus, and are helpful for users with a physical disability. Keyboard users must tab through the web page to reach the particular link they are interested in—skip links allow lengthy navigation to be bypassed and reduce the number of key presses required to activate links in the main content.

Avoid moving targets Avoid using moving targets such as tickers, as users with a physical disability can find them very difficult to use.

Provide large clickable areas

provide sufficient whitespace between links

People with a cognitive or learning disability may have difficulties with memory, problem solving, perception, and conceptualization. In addition, people with a learning disability may have issues with reading and comprehension such as dyslexia.

To enhance the usability of the website for these users it is important that content is written in plain English, page layouts are simple in design, navigation is clear and consistent and there is no moving content to impede comprehension.

Provide the same look and feel throughout all pages of the website. Ensure that the navigation and main content are located in the same area of every page. Additionally, consider color coding different sections within the website. Users with cognitive or learning disabilities tend to find it easier to navigate around sections which are color coded.

Provide a site map A site map will enable users with a cognitive or learning disability to have a clear idea of the breadth of content contained within the website. The site map also enables users to directly access any page on the website, and helps if the user becomes lost.

Use a resizable sans-serif font which is left-aligned To increase readability for users with a cognitive or learning disability, use a sans-serif font which can be resized. Additionally, left-align content—justified text is more difficult to read due to the uneven spacing between words. Italicized and capitalized text should also be kept to a minimum to aid readability.

Provide helpful error messages

Offer speech output Organizations such as Browse Aloud and Textic enable content from a website to be spoken when highlighting the words on a web page. Offering this functionality is especially helpful for users who find it difficult to read large amounts of text.

Provide an Easy Read Version Consider providing an ‘easy read’ version of complex content. This combines plain text with images to aid understanding of the information. For an example of an easy read document see the Department of Health’s Making Lives Better for People with a Learning Disability.

Provide different color schemes People with cognitive or learning disabilities may benefit from different color scheme options. It is helpful if an easy read scheme such as a lemon background with dark text, and a hi-viz scheme such as a black background with yellow text, are provided.

This argument is a development of the age-old mantra from the accessibility sector that people with disabilities want to use the web in the same way as everybody else - “it is a human right recognised by the UN,” says Abou-Zahra. But he recognizes that businesses in particular will also  be interested in the additional business benefits, especially in the current financial climate.

“With commercial organisations the return on investment is often an important argument. Well, a few years ago, companies might have said ‘how many older people are online?’ but with demographics changing they know the answer. And with the current surge in mobile phone use there is another incentive, since accessible sites work better on mobile phones.”

Another change of style will be a greater separation between the core guidelines and references to specific technologies such as Javascript or browser types, Abou-Zahra says.

“WCAG 1.0 was too  technology-specific. Back then HTML was more dominant, and there was less use of multimedia, but today we have a flurry of technologies such as Ajax, so the first lesson we learned is don’t write for a specific technology. Also, in the days of WCAG 1.0 we had to exclude Javascript because it was not sufficiently standardised and  assistive technology could not handle it consistently, but now that has largely changed so you need to include it, to look at how any technology should be accessible. The requirements - such as tagging images with text - needs to apply to any technology you are using.

Because of the problems caused by WYSIWYG editors I have toyed with the idea of providing a much simpler interface for content editors. Markdown, BBCode, and Textile are a few possible solutions that ensure valid markup and increase the likelihood of it being semantic. The problem would be making clients accept working that way, directly editing pseudo markup. Most clients wouldn’t, so that option is ruled out.

But there is another kind of editor that is better suited than WYSIWYG for content-driven, client-edited sites - the WYSIWYM (What You See Is What You Mean) editor. In Visually Editing Semantics - What You See Is What You Mean, Peter Krantz mentions one such editor: WYMeditor.

From the WYMeditor site: Our goal is to create a XHTML strict web-based editor which will be usable on many platforms, whith the help of the Open Source Community.

There are a few limitations, of course. This is an early version, after all. Besides the issues Peter notes in his post about WYMeditor, here are a few more things I noticed: Table accessibility. There is no way to add elements and attributes (th, caption, scope, etc) needed for accessibility to data tables. Table resizing. It is possible to size tables by dragging handles. Doing so is reflected in the markup. That needs to be filtered out at some stage before saving the page to the database. Incorrect nesting of lists. When you create nested lists, the current list element is closed before the next level ul or ol is inserted.

The XHTML and CSS elements can be dynamically modified to display new information or styling. These changes are typically done using the Document Object Model.

XHTML (or HTML) and CSS to create an interface and visually style information.

JavaScript is used to manipulate the interface elements and is also used to establish a communication with a web server through XMLHttpRequest. This allows data (typically in XML format) to be transmitted between the client and the web server without requiring page reloads or refreshes.

standard type of client-server interaction

A web page interface is presented. User information is collected (via forms, links, etc.). The user submits information (submits form, activates link, etc.). The server processes submitted information. A new web page interface is sent to the user.

With AJAX, all of these steps can be handled in one interface.

The types of web applications and interactions allowed by using AJAX has given rise to the term "Web 2.0"

AJAX allows feature-rich, dynamic web applications which use server-side processing without requiring the traditional "submit data — retrieve web page"

allows more streamlined applications that require less processing and data transmission

higher levels of interactivity

current solution to these problems is to either provide a non-AJAX alternative to your application or to allow your AJAX application to continue to function if JavaScript and XMLHttpRequest are not supported. Such a requirement may be very difficult to achieve

Another issue with AJAX is how the application interface is updated. When updates to the interface occur, it may not be visually apparent that a change has occurred. The problem is even more troublesome for screen reader users. Screen readers typically read in a linear fashion. When changes happen in the interface, the screen reader user may not be aware of the change and the new content will likely not be read.

to allow dynamic interface changes to be accessible, the application must alert the user that a change has occurred, allow direct access to the new content, and then allow continued functionality of the web application. This process, while difficult to achieve, especially for screen reader users, is possible to achieve in many AJAX applications.

anecdotal evidence suggests that, as soon as you reduce the colour contrast, the reading difficulties suffered by dyslexics are alleviated, to some degree, across the board.

Contrasts that comply with the thresholds can, and do, create very real problems for dyslexics.

t has been my experience that just about every issue within accessible web design is about balance. Skew any one factor too much in favour of a particular user group and you risk disadvantaging another group with opposing needs.

What I am suggesting is that, if a colour theme is chosen that conforms to, or exceeds, the W3C colour difference threshold, an alternative, low contrast style sheet should be provided as standard.

I then suggested that “disability” be defined as an “inability to pursue an activity because of a medically determinable physical or mental impairment.”

suggest that adhering to the Hewlett-Packard colour difference threshold would represent a more balanced approach to the issue of colour contrast. To that end,

I’ve developed an alternative color contrast analyser for people to try.

The law about accessible websites came into force on 1st October 1999 (http://www.drc-gb.org/open4all/law/code.asp) and the Code of Practice for this section of the Act was published on 27th May 2002 (http://www.hmso.gov.uk/si/si2002/20020720.htm). This means that the majority of websites are already in breach of the law.Can you be sued?Well, probably. The RNIB claim that they've considered taking up a number of legal cases against organisations with regard to their websites. When they raised the accessibility issues of the website under the DDA, companies have typically made the necessary changes, rather than facing the prospect of legal action.The DRC has now published their findings from their formal investigation into 1000 websites. (http://www.drc-gb.org/publicationsandreports/2.pdf). If your website was included then you will have to start thinking about making it accessible to all web users in the very near future.

What do you need to do to comply?It's widely believed that if, or perhaps more appropriately when, a case makes it to court that the W3C accessibility guidelines will be used to assess a website's accessibility and ultimately decide the outcome of the case. The W3C is the Internet governing body and its web accessibility guidelines can be found at http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html.