All 4 entries tagged Video

View all 651 entries tagged Video on Warwick Blogs | View entries tagged Video at Technorati | There are no images tagged Video on this blog

July 24, 2007

Accessibility of Rich Media – Part 4 AjaxAccessibility

Follow-up to Accessibility of Rich Media – Part 3 Flash Accessibility from Sara's Mindbloggeld

This part of course was run by Mike Isofaro and I see he has kindly put his presentation the web. So I don’t need to say to much here, it seemed like the key messages were:

Start developing from semantically and well structured HTML, onto which you graft ajax and javascript. (Then if javascript is off you will have a good fall back position and also the screen readers should cope better reading your pages).

You could use display:none to hide stuff you don’t want the screen readers to read.

Screen readers may not detect on screen changes. In which case you might want to try updating a hidden input field to force the screen readers to spot a change and read whatever has appeared.

Or keep a log of background updates and use the access keys to jump to and read the log.

Keep new content near the last action so it is easier for screen magnifiers to spot what has changed.

Check with a keyboard and make sure the focussed elements are always on screen.

Testing:

Check with a keyboard, with javascript off, with a slow connection and with a competent screen reader user.

Links
http://www.isolani.co.uk/blog/access/AbilitynetRichMediaAccessibleAjax


Accessibility of Rich Media – Part 3 Flash Accessibility

Follow-up to Accessibility of Rich Media – Part 2 PDF Accessibility from Sara's Mindbloggeld

Unless carefully developed Flash presents accessibility barriers for many people with physical disabilities, however it is important to realise it is a medium that can enhance accessibility for many.

Because of the MSAA approach (a database that feeds out flash content to assistive technologies – flashes accessibility implementation) Flash accessibility features are ONLY available to the player that runs in Internet Explorer on Windows. However accessible your Flash content is it will not work with a screen reader on the Mac or Linux platforms

Flash 8 makes it easier to set the reading order in a movie because you now only need to set specific values for relevant objects – you don’t need to set an order for all of the flash elements on the page as you do in Flash 7

NOTE: If you use static text anywhere in a movie it destroys your reading order and sets it back to the default top left to right and then down the page – testing is very important!

Having heard this I do wonder whether static text could be avoided completely in favour of dynamic or input text.

Setting accessibility features via the accessibility panel is still the means of setting accessibility features, or accProps if coded directly through ActionScript. For a full guide to they recommended Adobe Best Practices document. Had a quick look at this link just now and it looked pretty good there is a table that covers the accessibility of 22 components within flex.

Web Content Accessibility Guidelines 2.0 WCAG try to encompass guidance for Flash and PDF but are still draft.

Accessibility Tips:

  • Ensure good colour contrast
  • Don’t convey info with colour only
  • Make use of ‘anti-alias for readability’ on text
  • keep a consistent layout to make life easier for magnification users and others who take longer to process information – apply good usability principles and this will benefit all users
  • Ensure any sound can be quickly switched off
  • Make sure buttons and controls are properly labelled
  • Be careful with looping animations, these may cause a screen reader to return to the top of the page every time the movie refreshes
  • make sure the reading order is logical
  • consider that some users may not have full mobility so drag and drop becomes an issue, click and drop is easier for them
  • can the application be navigated via the keyboard only? – voice recognition users have to fall back to a system called mousegrid where they move elements around a numbered grid
  • provide captions or sign language (signers use a different vocabulary than spoken english so signing is better than captioning)

Something that occurred to me during the course was the principle of not getting in the users way. So if you can use an external stylesheet for as much styling of fonts, colours etc. as possible then this could be overridden by the screen readers preferences or accessibility stylesheets which would be much better. Particularly given that different options work for different disabilities one set of colours does not work for all dyslexics for instance.

Accessibility Testing

  • Check is whether the application can be used via the keyboard only
  • Check audio can be turned on and off on each page
  • There is good contrast between text and graphics
  • The navigation is easy to use
  • An intermediate level of checking can be achieved by using a screen reader yourself
  • The best testing is via feedback from both a novice and competent screen reader user

Links:

http://www.signacademy.org.uk/
Web Accessibility Toolbar


Accessibility of Rich Media – Part 2 PDF Accessibility

Follow-up to Accessibility of Rich Media – Part 1 Mostly Multimedia from Sara's Mindbloggeld

Since Acrobat 5 PDFs started to become accessible. Adobe introduced a series of “tags” that could be used to enhance PDF accessibility.

PDF files should be used to display documents that need to be printed exactly as the author intends. Not as an alternative to HTML. Note that PDF documents containing columnar data, such as financial data are likely to be inaccessible to screen readers so consider publishing in another format as well.

As with HTML, you need to know what kinds of issues people with disabilities might encounter when reading PDF files.

Accessible PDFs must:
  • Be created as well structured documents (using hierarchical heading levels as you might in HTML).
  • With a clear reading order (for the screen reader to follow)
  • Images should have alt text
  • Not contain hot spots that are too small or hard to click on
  • Provide good colour contrast
  • Use clear and simple language
  • Not have information relayed in colour only

NOTE: An easy way to detect whether a PDF has been created with accessibility in mind, is to open the Tags tab on the left, if you can see some document structure revealed there, then PDF Tags have been created.

Three ways to generate tagged PDF:
within MS Office when creating the document
by running the “make accessible” plugin on existing PDF documents
by hand create the PDF tags within code view yourself (but this is time-consuming)

Within MS Word (this will vary depending on the version)

To create a hierarchical structure
Use the heading styles to set different heading levels.

To create Alt-Tags

Select the image, then click Format, Picture, Web in the Alternative text window that appears enter your Alt Text.

Set the Doc Type
Like with HTML document type definitions you need to specify the language as english.

NOTES:

Finally you can run an ‘accessibility quick check’ to verify the accessibility of the pdf document within adobe acrobat 6.

Link:

There is a large .pdf document from Adobe on PDF accessibility.


Accessibility of Rich Media – Part 1 Mostly Multimedia

Went on a course last Tuesday about accessibility of Flash and Ajax applications, also thrown in was a bit on Multimedia and making PDFs accessible.

Initially I was kind of frustrated with it, as no ‘magic bullet’ for the testing of Flash or Ajax was given, or much progress in the making of Flash applications referred to beyond the initial Flash Accessibility Whitepaper. However having mulled it over for a while, I guess accessibility is just one of those areas that requires time and forethought and for which there is never going to be a quick fix.

Here’s a summary of what I thought were the best/useful bits:

Multimedia

Video – if you are producing video for the web you should also produce:
  • a transcript file (might also describe background sounds like music, does not have to be exact)
  • an audio descripton (necessary to describe anything that is only relayed visually)
  • include captioning (and better still include someone signing) – captions should have good contrast be 12pt or larger and sans serif, i.e. Arial, Tahoma or Verdana.
  • make sure that sound can be quickly switched off

If you can also produce for different players (quicktime, realplayer, media player) as each has different levels of accessibility

MAGpie tool was used to produce captions for multiple formats.

Hi Caption SE was also deemed to be a flexible and straightforward means of captioning Macromedia Flash by streaming XML data at runtime

...more on captioning and examples

Media player accessibility
The different players each have different levels of accessibility and it also mattered whether they were used embedded or standalone. Here’s a chart ‘6’ is the best though 7 was possible and 1 was inaccessible. As you can say apart from the Quicktime player all the embedded players had a low accessibility score.

6 Windows Media Player 7 (Standalone)
6 Windows Media Player Series 9 (Standalone)
6 RealOne Player Basic (Standalone)
4 Quicktime Player 5 & 6 (Standalone & Embedded)
4 RealMedia Player 8 Basic (Standalone)
1 RealOne Player Basic (Embedded)
1 Windows Media Player 7 (Embedded)
1 Windows Media Player Series 9 (Embedded)
1 RealMedia Player 8 Basic (Embedded)

NOTE: Captions do not appear by default in Windows Media Player, the option must be switched on in the preferences. It may be worthwhile providing a guide including common shortcuts and common tasks as done by ‘Skills for Access’.

NOTE: It occurs to me that it may be a red herring to get obsessed about this table, to the extent that you publish only in the most accessible players. As from experience working with a disabled user, chances are they will stick with the player they know, if they have picked one that is bad, the cost of change is still too high for them to learn something else. I would be more curious to see a chart that said the most favoured players by users of screen readers and/or users with different accessibility requirements.

Accessibility Testing
For multimedia, flash and ajax, the recommended approach was to test as follows:
  • A quick check is whether the application can be used via the keyboard only
  • Intermediate check using a screen reader yourself
  • Best testing is with competent screen reader users
  • For Ajax also test on a slow connection and with javascript off

As this blog entry is getting a bit long, I’ve decided to split it up into parts.
See you in Part 2.

Links:

Lecturer discussing her disability and assistive technologies

Joe Clark on Media Players


February 2012

Mo Tu We Th Fr Sa Su
Jan |  Today  |
      1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29            

Search this blog

Tags

Galleries

RSS2.0 Atom
Not signed in
Sign in

Powered by BlogBuilder
© MMXII