Accessibility of the Wikimedia websites: Difference between revisions

From Wikimedia UK
Jump to navigation Jump to search
mNo edit summary
m (cat)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{notice|Please note that the content of this page is not currently CC-BY-SA licensed. The paper below makes extensive use of copyrighted content prepared by the [http://www.rnib.org.uk Royal National Institution for Blind People] with kind permission.}}{{TOCright}}
 
==Background==
==Background==


Line 12: Line 12:
When websites are accessible to these groups then people using older browsers and slow internet connections also benefit.
When websites are accessible to these groups then people using older browsers and slow internet connections also benefit.


==Options==
The RNIB (Royal National Institute of Blind People) is the leading charity offering practical support and information to anyone with a sight problem and has developed [http://www.rnib.org.uk/professionals/webaccessibility/designbuild/Pages/design_build.aspx guidance to 'design and build accessible websites'] which we propose to work from.
 
The internet is accessed by people with disabilities in a number of ways
#via a screen reader
#via a Braille display
#with large text and colour options for example zoom text
#using video description for pictures
#using ‘sub titles’ for the deaf
#via speech activated software
 
People may use specialist software or they may rely on the website provider to make the website accessible, with for example text size buttons.
 
==The problem with wiki==
*Wiki sites generally do not have text size or colour changing buttons
*The format and content is often presented in a way that is both irritating and obstructive for screen readers for example while the formatting is not visible on the screen, in the older HTML format all the formatting is read out by the screen reader or it is noted on the Braille display
*No tags are attached to pictures to describe them
 
A specific wiki problem is that the pages are designed to be live and altered all the time so the accessibility options need to be 
 
==The solution==
 
A project that will enable the development of tools to allow editors to
*Use techniques such as those listed below at the same time as editing
*An add on to the editing education programme to teach how to make websites accessible including the correct use of alt text
*A communication programme to encourage editors to add things like alt text to pictures etc
 
In house we need to make WMUK’s own website comply
 
This project needs to look at the use of:
 
*CSS - layout and positioning, text and colours, etc
*Colour - used alone and contrast
*Images - alt text, animated images, image maps. Images of text
*Multimedia – audio and video, flash, PDF’s
*Navigation - access keys, links, help pages, hidden navigation and tab index, website navigation, new windows, page titles
*Scripts and forms - dynamic menus, forms, java script, time outs and page refreshes
*Structure – CSS, data tables, doc types, frames, layout tables, metadata, page structure
*Text – acronyms and abbreviations, ASCII text, font sizes, language, text only websites, sitemaps. Writing for the web
 
This follows the key areas highlighted by the Royal National Institute of Blind People regarding website design. Below are links to the relevant pages which contain useful information on each subject.
 
==CSS basics==
:''Full details can be found [http://www.rnib.org.uk/professionals/webaccessibility/designbuild/cascadingstylesheets/Pages/css_basics.aspx here]''
 
Using HTML to format a web page can lead to bulky, inefficient and repetitive coding. In addition, using HTML to visually format a document can interfere with its structure.
 
Using CSS can make web pages more accessible. By removing formatting from the page it becomes much easier for users to control the size and colour of page elements to suit their needs. If they require a special size of text or colour combination for ease of reading they can define their own style sheet.
 
In addition, the cleaner, leaner HTML is the easier it is on the ear for audible screen reader users. The old style of layout, using tables, might have been invisible to the eye, but as tables were intended to be a structural element for displaying data in a grid, screen readers are programmed to read this structure aloud. So the first information screen reader users get on a page using tables for layout is the number of columns, rows and nested tables used, which apart from being time-consuming, is frustrating, as the user knows that the same information is likely to delay their enjoyment of every page on the site.
==Colour used alone==
:''Full details can be found [http://www.rnib.org.uk/professionals/webaccessibility/designbuild/colour/Pages/colour_alone.aspx here]''
===Rationale===
Not everybody can access colour. A user with a screen reader or braille display cannot see colour and the software cannot interpret colour. Colour-blind users may have problems differentiating between some colours. Users with low vision may also browse with colours switched off or using their own style sheets. PDA (Personal Digital Assistant) or text based browser users also may not be able to view colours.
 
However, using colour to reinforce information, rather than relying on it to convey the message, can act as an enhancement to accessibility. People with cognitive problems, the elderly or children may rely on colour to enhance understanding of information and for highlighting navigational aids. So colour, when used along with another means of identification, can be considered a visual aid.
 
===Techniques===
*'''Graphs and charts''' should go beyond just colour coding to convey information. Use patterns and text to indicate change. Pattern in a pie chart for example gives a visual indicator to a user viewing in black and white. Text is necessary for a screen reader, braille output or text-based browser user.
*'''Colour coding navigation''' is an excellent way to provide an additional means of indication to where a user is in a site but cannot be used alone. Ensure that the page has a clear TITLE element and structured headings to confirm which page it is. In addition to this a heavy font weight can be used for the navigational link of the current page.
*'''Using a different colour''' for linked phrases is a good visual indicator of links but not distinguishable if a user has a monochrome browser or is browsing with colours switched off. Using underlining in addition to the colour is standard practice to make links obvious. This is especially important for links contained within a paragraph of content.
*'''Coloured regions or borders''' can be used to create visual separation in a page making the page easier to understand when read visually. Make sure however that grouped information within borders also has some structure such as a correctly marked up heading or structured lists. A screen reader or braille display will then be able to interpret this. 
A good use of colour to enhance layout and readability is to use alternating colours in rows or columns of a data table. This vastly improves the readability of a table when a page is accessed visually.
*'''Provide colour in a way''' that ensures that people can override the colours you specify via their browser. By using flexible CSS (Cascading Style Sheets) you can allow people to customise your pages to suit their needs. This way you can use the colours you want but a user is able to change colours if they need to.
*'''Colour alone''' should not be used to convey information. For example a red button and green button to indicate stop and go. Adding ALT text to the image of "Go" and "Stop" will make the images screen reader, braille output and text-based browser accessible. This in itself is a requirement of WCAG (Web Content Accessibility Guidelines) version 1.0 Checkpoint 1.1. however, you should also use two different shapes, as well as colour, to make them visually different and more user-friendly, for those with colour blindness.
*'''Coloured text alone''' should not be used to convey meaning. For example in forms don't say, "All fields marked in red are obligatory" as the colour difference won't be conveyed to screen reader, braille output and text based browser users. Use red together with an asterisk (*). This will then be clearly visible to users with monochrome browsers and conveyed to speech and braille output users.
 
==Colour contrast==
:''Full details can be found [http://www.rnib.org.uk/professionals/webaccessibility/designbuild/colour/Pages/colour_contrast.aspx here]''
===Rationale===
People with cognitive or sight problems may have difficulty reading and distinguishing text from a background colour. This is generally caused by poor choice of colour and contrast in the design of the page. Background images and patterns may also cause problems of legibility.
 
Creative use of colour and contrast can dramatically enhance the accessibility of a website. It can be as important for people with sight problems as it is to people who have dyslexia or whose first language is not the main language of the site.
 
Everyone benefits from text which is both easy on the eye and that is easy to follow. For example, people with dyslexia benefit from good contrast as this can help make the structure of words and sentences easier to understand.
 
===Techniques===
*'''High contrast''' must be provided between text and background colours. Pale blues and grey will not be easy to read on white backgrounds but dark blues, black or reds will. 


*'''Bold and large fonts''' can sometimes compensate for colour contrast that is a borderline fail using the WAI algorithm. If a piece of text is large, then the contrast may be less critical. Good judgement is required to assess this.
*'''Colour blindness''' affects the way that certain colours differ from others. Red and green, for instance, can appear to be virtually the same to some users. Ensure that you choose colours that have a good differentiation for people with colour deficiency. You can find out more on the Vischeck website ).
*'''Images''' must also have good contrast, especially if there is text on the image. Always check that logos are high contrast and tag lines within logos are readable. 

Ensure that images do not lose definition when style sheets are disabled. This can result in text appearing transparent on an image. To prevent this, ensure there are no transparent colours around the text on the image.
*'''Background images''' can sometimes interfere with the legibility of text. Watermarks or patterns can be problematic so where possible avoid them, or ensure they are either not behind text or that they do not interfere with its legibility.
 
==Alt text==
:''Full details can be found [http://www.rnib.org.uk/professionals/webaccessibility/designbuild/wacimages/Pages/alt_text.aspx here]''
===Rationale===
If you have no eyesight or low vision, images cannot be seen, but by using screen readers or braille displays they can be heard or read. This is made possible by providing alternate text or ALT text as it is referred to. Screen readers and braille displays interpret an image on a page by searching for the image's ALT text, which is read aloud to the user.
 
If ALT text is missing from an image, the screen reader will often read out the image file path or simply say "image" instead. In the case of the "RNIB" image, they would hear "logo_rnib.gif" if there was no ALT. This can be extremely frustrating if there are several images on a page. If images are used as links the site then becomes impossible to navigate and will fail to pass Checkpoint 13.1 of WCAG 1.0 (Web Content Accessibility Guidelines) "Clearly identify the target of each link".
 
ALT text is also the text that replaces an image in a text-based browser such as Lynx or in PDA's (Personal Digital Assistants) and mobile devices that cannot support images.
 
Good ALT text can help provide context and "look and feel" to a blind user. It is also a good medium for providing audio branding to a site as well as being an important marketing tool, because search engines are also "blind" and can't index image content unless it has a text equivalent.
 
Overall, images with good ALT text will not only make a site more accessible to blind and partially sighted users but also enhance the accessibility of a page to someone who has dyslexia or learning difficulties. Images are a visual aid and are often easier for some people to follow than text.
 
==Animated images==
:''Full details can be found [http://www.rnib.org.uk/professionals/webaccessibility/designbuild/wacimages/Pages/animated_images.aspx here]''
===Rationale===
It is important to avoid using animation that can cause the screen, or parts of it, to flicker and change rapidly. Although animated images can be useful to draw attention, using lots of them can detract from the accessibility and usability of a page. Instead of simply attracting the eye they can become an annoyance and a distraction.
 
Scrolling text and animated images of text can be difficult to read as we all have different reading speeds. They are an added problem for screen magnification users who view a fraction of the screen at a time. Often the animated image or scrolling text will dominate the screen and be unreadable.
 
Other people are susceptible to certain types of strobe or flickering effects. These can trigger epileptic fits, cause problems for people with cognitive impairments and be hard to read for people with low vision.
 
===Techniques===
*'''Animated images''' should be kept to a minimum and not used to convey primary or large amounts of content. The animation should also come to a rest after 3 to 5 cycles. The speed at which they rotate should be reasonable and leave users enough time to read text where text is present. 
All animated images must also comply with WCAG (Web Content Accessibility Guidelines) version 1.0 Checkpoint 1.1 and have clear and appropriate ALT text.
*'''Scrolling text''' is often used in the form of news tickers in websites. Text should scroll slowly and at a reasonable pace. Ideally it should come to a rest or a switch should be provided to switch the ticker on or off.
*'''JavaScript''' animation of images or text must be given an HTML alternative so the same content is available when JavaScript is switched off or not supported. This may be a textual representation of the content, provided within the <NOSCRIPT> element, or a link to where a page of equivalent information can be found. 
In addition, care should be taken that the script doesn't interfere with the flow of reading for screen readers. Some scripts effectively call a fresh image for each change in the animation, and this can act like a page refresh, forcing the screen reader to begin again from the top every time the image changes. Where this happens, blind users will be unable to read the whole of the page
 
==Image maps==
:''Full details can be found [http://www.rnib.org.uk/professionals/webaccessibility/designbuild/wacimages/Pages/image_maps.aspx here]''
===Rationale===
Image maps are pictures with a number of clickable areas used as navigation. Because of their graphical nature they cause a number of accessibility issues if not constructed properly with ALT text for clickable areas and alternative text links for these areas.
 
Image maps come in two varieties: server side and client side. Server side image maps should be avoided altogether, as they require people to use a mouse to operate them. This means they will be impossible to use for someone who has limited movement or cannot use a mouse.
 
Image maps should really be regarded as a visual aid in that the information they contain is provided in an alternative format elsewhere on the page, such as text links. Text links are easier for screen magnification users to access, as image maps can be difficult to navigate around. That said some users, such as people with dyslexia, might find image maps much easier to use than text links.
 
===Techniques===
*'''ALT text''' must be provided for the image map as a whole. For example, if the map is of the United Kingdom and its different countries the overall ALT text should be "Map of the United Kingdom". Each hotspot should then have individual ALT text as described below.
*'''AREA ALT text''' must be given to each AREA element or "hotspot". The clickable area must be given ALT text indicating the target of the link. Using the example of a map of the UK and the four clickable areas of England, Ireland, Scotland and Wales ALT text for each AREA would be "England", "Ireland", "Scotland" and "Wales". 
Alternative text links must also be provided elsewhere on the page. This benefits users of screen magnification who may not be able to fit the whole map on-screen, or who find it problematic to navigate. It also makes the links accessible to users who do not use a mouse and therefore cannot benefit from the ALT text tooltip.
*'''Alternative HTML links''' should be given elsewhere on the page. These are best presented as a correctly marked up list.
 
==Images of text==
:''Full details can be found [http://www.rnib.org.uk/professionals/webaccessibility/designbuild/wacimages/Pages/images_of_text.aspx here]''
===Rationale===
People who use screen magnification software view images at many times the size they were designed to be seen. When this happens images can become pixellated and very difficult to read and sometimes make no sense at all.
 
Other people, who need to adjust browser or computer settings to view text at a readable size lose the ability to make text bigger when it is presented in images. It is important to realise that they will also not be able to change its colour and contrast within their browser, as they would with text.
 
People with a low vision may use computers with low colour palettes or high contrast settings. This means they can't display the colours in the image correctly. For this reason actual text should be used. This makes your pages more flexible, customisable and easier to navigate. As an added bonus, search engines cannot index text within an image, so replacing them with text will increase their ability to do so.
 
==Multimedia==
===Audio and video===
:''Full details can be found [http://www.rnib.org.uk/professionals/webaccessibility/designbuild/multimedia/Pages/audio_and_video.aspx here]''
====Rationale====
Audio and video are great tools for communicating information to your audience. If used correctly they can also enhance the accessibility of a website by becoming additional means of providing information. Audio and video can also be great for learning.
 
The problem is that, without text alternatives, audio and video is inaccessible to people who are deaf, blind or both deaf and blind. In addition to this not all users will have a media player or support for a media player such as Real, QuickTime or Media Player.
 
Providing audio and video content should be thought of as a visual aid, and not the primary means of presenting content. When used alongside an accessible alternative, audio and video can considerably enhance the accessibility of a page. For example people with cognitive or language problems will find it easier to absorb information when they can hear or see it.
 
====Techniques====
*'''Text transcripts''' to the audio or video must be provided in HTML format. This can be just a text transcript on the page where the audio is linked to or it can be static images (with good descriptive ALT text) and accompanying text on a web page. If the audio track contains speech, provide a text transcript. This is fairly straightforward for speeches or news pieces. 
If the video is more conceptual good judgement is required as to what information is included in the transcript. For example video of a dance would need a transcript detailing who, time, place and a conceptual overview of what is happening rather than a word for word description.
*'''Alternative content''' should be provided within the OBJECT element. This should be a brief description or title of the content and instructions of where else it can be accessed. This will be picked up by assistive technologies and text-based browsers (which do not support audio or video) as well as by some search engines.
*'''Controls''' such as on and off buttons should be provided in video and Flash movies that have sound. Sound in a movie can conflict with a screen reader so the user should be given the ability to start and stop it.
*'''Link to media player''' downloads so that a user can download a player or update an older version player, if they have browser support for one.
*'''Provide captioning''' where possible for video. A transcript should be provided in closed captions and encoded into the audio or video track itself. Where possible this should be synchronised with the audio or video track.
Web casts are very difficult to provide alternatives to in real time. WAI (Website Accessibility Initiative) guidance states that alternatives do not have to be presented in real time and can be added retrospectively.
 
===Flash===
:''Full details can be found [http://www.rnib.org.uk/professionals/webaccessibility/designbuild/multimedia/Pages/flash.aspx here]
====Rationale====
The release of Flash MX 2004 (version 7) has made Flash much more accessible than it has previously been for many users. This includes users with hearing impairments, low vision (screen magnification users) and blind users ie screen reader users who are the main group of users encountering barriers of access to Flash.
 
Following accessible Flash design guidelines will go a long way toward making your Flash animations accessible to these various groups. However we do still advise that accessible alternatives be provided.
 
The key issues are that it can be problematic for users with screen readers to navigate around and access information. Screen magnification users also can still encounter problems with navigating and understanding information. Both of these user groups may have problems with establishing the context of the Flash. Finally, text-based browser users can not view Flash at all.
 
====Techniques====
*'''Provide text equivalents'''' for all objects in the animation that are related to content and, or, functionality. This will be picked up by screen readers and read to the user just as ALT text is for images in HTML. 
This can be done via the accessibility panel in the Flash-authoring tool. The option to "Make movie accessible" should be checked along with "Auto label" and then either a name or description should be given. There is no need to give both a name and a description as this results in the screen reader user having to listen to a lot of redundant information.
*'''Hide unnecessary content''' from the screen reader user. Just as text equivalents should be provided in the accessibility pane by using name or description (see above "Provide text equivalents") non-content related objects should be hidden. This can be done in the accessibility panel by deselecting "Make movie accessible".
*'''Ensure good contrast''' in the animation so users can easily read text and see images. Good judgement is needed and colour choices can be tested against W3C (World Wide Web Consortium) algorithms. A useful feature would be to provide users with a variety of colour options to choose from.
*'''Do not use colour alone''' to convey meaning. This is because not all users can see colour, so will miss the meaning the difference of colour is indicating. Colour can and should be used, of course, but do ensure that the object has a name or description for screen reader users. Different shapes or patterns can also be used to convey meaning; which is especially useful for low vision users.
*'''Allow screen magnification''' by making available the option to scale the animation by right clicking with a mouse and selecting "Zoom in" and "Zoom out". For non-mouse users this option could be given as a set of buttons in the animation for "Small", "Large", "Larger" and "Largest".
*'''Provide on/off switches''' for movement. Movement can be distracting for some users, especially screen magnification users who only see a small part of the screen at a time, so on off switches should be provided.
*'''Control the reading order''' of objects within the Flash animation. This is essential for screen reader users, as they are unable to visually scan animations the way a sighted user does. A logical tab order can be applied using ActionScript, limiting the size of the stage and keeping the animation simple, or creating a linear version of the content offstage.
*'''Caption audio content''' for those users who may have hearing impairments or no sound facility in their software. This can be done in one of three ways. A video, already captioned, can be imported into the Flash animation, text objects can be provided as alternatives or an XML caption file can be streamed in.
*'''Provide context for Flash animations''' so users with visual impairments can gain the same understanding or feel for the animation as a sighted user might. For example, if there is a Flash animation of a room, provide a description that sets the scene. Ideally this should be available to both screen reader users and low vision users. This could be in a "help" or "about this site" section. That way a visually rich and exciting sight can be made more exciting to screen reader or low-vision users.
*'''Ensure keyboard access''' to all buttons and controls within the Flash animation. This is essential for non-mouse users such as users with mobility problems or screen reader users. Ensuring keyboard access must be checked both with a screen reader and without a screen reader.
*'''Link to Macromedia''' so that those users who would like the Flash plugin and haven't got it can find it easily from your page.
Accessibility checking extensions can be downloaded and installed in the Flash authoring software. Download details can be found on the Macromedia site, a link to which is provided below in the Further information section.
 
==Adobe Acrobat PDFs==
:''Full details can be found [http://www.rnib.org.uk/professionals/webaccessibility/designbuild/multimedia/Pages/pdf_documents.aspx here]
===Rationale===
Portable Document Format (PDF) documents are used for information intended for download. To read these documents browsers must have the Adobe Acrobat plugin installed. Not all browsers, for example text-based browsers, can support this plugin however. In addition to this screen readers and braille output struggle to read this format.
 
Adobe has done a lot of work toward making PDFs as accessible as possible. Acrobat 7 Professional and Standard have full tagging tools and an accessibility checker to enable the production of accessible tagged PDFs.  


===Techniques===
<!--''(The remainder of the text of this page has been deleted pending a review of its licensing. Volunteers and/or staff might like to work on re-instating the information in some legally-allowable way, eg by linking)''-->
*'''Alternative formats''' should be provided for PDF content where possible. If you offer a PDF file, consider having the same content presented in HTML, Word or text format. 
We strongly recommend that PDF forms have an alternative format provided, as they are particularly difficult to make accessible. Often forms are presented in PDFs as they are intended to be filled in offline, as they need a signature. Even when this is the case enabling the form to be filled in online is a huge benefit to many users.
*'''Create accessible PDFs''' using Acrobat's built in accessibility tools and checker. Ensure the PDF document has structure, correctly captioned images, and navigable content. Links to Adobe help and support can be found in the further information section below.
*'''Access Adobe help''' should be provided on every page that has PDFs, including links to Access Adobe and the PDF to HTML conversion tool. Additional help should also be given in a Help page elsewhere on the site. PDF help can be found in the RNIB help page.
*'''PDF link text''' should be intuitive and informative. Include information on the document contents, file format and size, so that users know exactly what they will get and how long it will take to download.
*'''New window warnings''' must be provided if PDFs open in a new window. This can either be in a piece of text at the top of the page, if there are a lot of PDFs; within the link text; in the ALT text if an image forms part of the link; or in text immediately preceding the link.


==Note==
[[Category:Accessibility]]
:'''''Elements of this page re-use copyrighted material from the [http://www.rnib.org.uk/Pages/Home.aspx Royal National Institute of Blind People], with kind permission.'''''

Latest revision as of 23:08, 30 January 2014

Background

The aim of the project would be to further WMUK's main aim, open knowledge by ensuring that all wiki sites are fully accessible to those with disabilities.

Web accessibility is a pan-disability subject and should cover

  • People with sight problems
  • Hearing problems
  • Mobility problems
  • Cognitive impairments

When websites are accessible to these groups then people using older browsers and slow internet connections also benefit.

The RNIB (Royal National Institute of Blind People) is the leading charity offering practical support and information to anyone with a sight problem and has developed guidance to 'design and build accessible websites' which we propose to work from.

Retrieved from "https://dev.wikimedia.org.uk/w/index.php?title=Accessibility_of_the_Wikimedia_websites&oldid=51129"