Free AbilityNet/Microsoft training sessions on UI Automation

From AbilityNet: Creating Accessible Applications with the User Interface Automation (UIA) Framework11th and 22nd June 2010.

This free course will discuss and demonstrate how to develop accessible applications using the User Interface Automation (UIA) framework.

This is primarily a developer-focussed course, since it will include coding demonstrations (using C#). However, it may also be of interest to a wider audience who is interested in understanding the capabilities of UIA.

The course format will be instructor-led, with a combination of slides and coding demonstrations.

The course is initially scheduled for the 11th June 2010 with a second run on the 22nd June 2010. Start time is 10am.

Lunch will be included, and the course will completed by 2pm at the latest.

The course will be held at the Microsoft Technology Centre at the Microsoft UK Campus in Reading, RG6 1WG. Directions.

The workshop will cover the following areas:

  • Introduction to Accessibility & Assistive Technologies
  • Why make applications accessible?
  • What is User Interface Automation (UIA)?
  • UIA and Windows applications UIA and Web (Silverlight) applications
  • Testing UIA

To register interest or to book a place on this course please email courses@abilitynet.org.uk or telephone 01926 464860 \ 0800 269545 with your contact details.

Group meet-up at BETT 2010, London, 13 January 2010

The Assistive Technology Specialist Group will meet up at the AT Fringe during BETT2010!

When: 4.30pm for 17:00h Wednesday 13 January 2010.

Where: Special Needs Fringe, Olympia Hilton, 380 Kensington High Street, Kensington, London. W14 8NL

What: The new BCS Assistive Technology Specialist Group is meeting over the road from the huge BETT Educational Technology show at Olympia in London. Come along to hear a presentation by a special Mystery Speaker and then meet your Group’s Chair, Alasdair King, and many other group members to discuss our activities for 2010!

You may like to spend most of the day in the massive BETT2010 Exhibition at Olympia which includes a big Special Needs section and hosts a BCS stand before coming over to see the specialist Assistive Technology stands at the Special Needs Fringe over the road. At BOTH exhibitions there are lectures on Assistive Technologies throughout the day on Wednesday. (and on other days!) Admission to the BETT2010 show and the Fringe Exhibitions is FREE. Refreshments will be provided before our meeting starts, courtesy of the BCS. Our grateful thanks to Inclusive Technology for the use of the room. Any queries do drop me a line on alasdair.king@bcs.org.uk or call me on 07983 244 131.

Demonstration of a screenreader end user browsing the web

If you’ve never observed an end user using assistive technology, or you’re familiar only with your own AT, it can be a real surprise how people operate when browsing, mailing, word processing and so on. While nothing can beat a session with an end user in action talking you through what they’re doing and responding to all your “but WHY do you do it THAT way?” questions, here’s the next best thing: a video of a screenreader user, Bruce Maguire, employing a refreshable Braille display (rather than synthesized speech) to browse the web:

There is also a full transcript of Bruce’s presentation. (Courtesy Roger Hudson at Web Usability)

GNU/Linux Live CDs for screenreader users

If you’re a real geek you’ve probably at least booted up Linux and played with Emacspeaks or Orca or Speakup. You’ve probably got at least one Live CD – that is, a CD you can boot that runs a working GNU/Linux operating system so you can fix your Windows installation – or you know, even try out Linux itself. Knoppix is probably the most famous.

Well, there are not one but two distros that let you boot, provide speech synthesis or even drive a Braille display, and use the machine straight away without installing any extra AT. Use the machine, install GNU/Linux, access the file system – all without a sighted friend coming in and pressing the buttons for you. Well, pretty much – see below.

Vinux
Vinux is built by Tony Sales of the British Computer Association of the Blind. Based on Debian. Uses Orca for the screenreader, runs off CD or USB stick. Probably the one to try out first.
GRML
Also Debian-based, but uses the Speakup screenreader. You have to type something when it boots to start the screenreader, but it comes to me recommended by a blind screenreader user, so it gets a mention. Maybe for the more geeky types.

So next time you break your machine by “accidentally” deleting a driver file “to save space” and you haven’t got round to backing up your machine even though you really really meant to this time – you can boot a Live CD and rescue your files without a sighted accomplice. Good luck!

Assistive Technology Specialist Group Mailing List

You can now subscribe to the BCS Assistive Technology Specialist Group mailing list for discussing AT and technology. We’re using Google Groups. You can join in one of two ways:

  1. Go to the website and enter your email address:Sign up to the mailing list with a form.
  2. Send an email to bcs-atsg+subscribe@googlegroups.com

 Alasdair will approve your joining, you’ll get an email, and you’re off! You can then send emails to bcs-atsg@googlegroups.com and they will appear on the list and go in the archive.

HTML Tables: how fashion affects Assistive Technology

“I like web pages with frames” a screenreader user told me in 2003. “They make it easy to differentiate the navigation bar and the content pages.” Back then, frames were well into their decline as a popular HTML technique, replaced by single-file HTML pages using TABLE elements. Everything was wrong with frames, including problems for blind people – confusing back and forwards, problems of positioning the focus and so on. The new TABLE layouts were much better, right?

Well, frames are pretty much dead as a design tool, and no self-respecting web developer would be seen dead using them. In fact, we are now going through the process of ditching the successor to the frame, using the TABLE element to lay out web pages. We’re moving to CSS-based pages. And arguments about accessibility for blind and screenreader users are being made in support of this shift (e.g. “Tables make life hell for those using screen readers” or “Tables Aren’t as Accessible” or “make your sites more accessible to all viewers and user agents” to give you the top three Google results for “layout tables are bad”.) There’s even a Web Content Accessibility Guideline, mandating what an “accessible” website should do, that says “5.3 Do not use tables for layout unless the table makes sense when linearized.

Is this true? What impact will the change to CSS have on blind and screenreader users compared to the current TABLE-based world? And what does it mean in terms of how we use arguments about accessibility to make decisions about technology?

Tables versus CSS: the technical details

Here’s why the use of TABLE elements is irrelevant to screenreader users and possibly even better than the CSS future.

Reason 1: Screenreaders handle layout tables just fine.

Tables for layout are the de facto standard, used on literally billions of web pages for over a decade. Screenreaders therefore handle them just fine. They’re a solved problem. Screenreader manufacturers do not generally insist that, for the sake of semantic purity, their users are inconvenienced by hearing extraneous and incorrect table formatting information as they browse the web.

Reason 2: Tables restrict designers to simpler layouts

Using tables means you have to segregate your page into relatively static and simple rectangles. The order of the content as it is encountered by the screenreader user has to reflect the order in which you code it, which means that navigation bars – usually left and top – generally come first. This is helpful for blind users because they can become used to “all the rubbish at the top” and come up with their own techniques for handling it, and the content when they do find it tends to be strictly linear and thus easier to use.

Compare this to PDF, where a page can hop about in terms of layout and floating text boxes and other things that confuse the all-important reading order. This kind of visually-effective design is much easier in CSS, and so will increase the complexity of web pages and hence decrease their usability for screenreader users.

CSS also permits much more variation in web page appearance during the page’s lifecycle, so suddenly you can do complex things like pop-up messages in CSS. Very Ajax, very hard for screenreaders.

Reason 3: CSS doesn’t give you any more semantics than layout TABLES.

It’s not like using CSS suddenly lets a screenreader user spot a search box, navigation bar or main content. CSS elements are arbitrarily named with non-standard tags. HTML5 might fix things – it has extra elements like NAV for navigation bar, which might actually be useful – but that’s going to be a long way off.

CSS3, of course, has a layout table anyway, so the Next Big Thing may well be – scrapping CSS for tables!

Reason 4: The implicit alternatives are “broken TABLE use” versus “utopian semantic web use”.

The latter isn’t going to happen. Most data is in PDFs or CVS. Everything else is in the tag soup of web pages. Maybe Wolfram Alpha will pull it out, but that gives one central point of reference – not arbitrary tables. Google gets information from links, not from page semantics – page semantics are too easy to game, as you’ll know if you tried using Alta Vista in 1999.

5 It should be easy to use heuristics to detect real data tables. They’ll need the extra semantics anyway.

The fact that content is laid out in a grid doesn’t really tell us that much. What do the columns mean? What’s the relationship between each item in each cell? Well, HTML gives us some extra elements which are actually useful – CAPTION, TH, SUMMARY. So a real data table is almost certainly going to use them.

Which gives us a convenient heuristic to differentiate data tables from layout tables: if it has the additional semantic elements then it’s a data table, otherwise it’s a layout table. So are we really missing semantics from the mis-use of the TABLE tag, or are we just missing actual non-layout TABLE elements from the Web?

7 TABLEs are relatively consistently and widely supported.

This means that people with alternative browsers are more likely to make sense of your layout, and the DOM for your access technology is simpler to parse and use. Known, older technology has better support from AT vendors, who always lag a few years behind, and from trainers and users and experts who need to build up techniques and approaches for new ways of doing things.

8 TABLEs scale better when you zoom the text.

CSS coders make assumptions: TABLE coders make assumptions. CSS assumptions don’t include people needing to zoom pages 400%, 1000% to read them. TABLE assumptions don’t include that either. However, because of how they are implemented in every major browser, and because they are simpler and lay out more simply, tables work much better when you zoom them up. Sure, you get a side-ways scrolling bar, but you don’t get overlapping text and columns squeezed to one character and rendered entirely unreadable.  Try it yourself with a table page and a CSS page.

6 Finally, CSS is harder than TABLEs: it’s a status symbol. The wasted time producing the same visual effect could have been used for accessibility.

First there were FRAME elements, then TABLE elements, now CSS. Professionals need a way to argue to their clients that their work is better than others: the ability to use hard-to-implement CSS is a form of display, a status symbol like a peacock’s tail. “Choose me, I can do this really hard thing! That means I’ll do a really good job of your site!”

What this all means for screenreader users and AT practitioners

If TABLEs are better than CSS, then what’s going to happen next? Can we fight it?

No. Let’s be honest: CSS is in, and layout tables are out. There is no way we’ll go back to TABLE use. The lesson to learn, therefore, is not that tables are better or worse. The lesson is that fashions and politics apply to coding and technology as much as they do anything else. Don’t believe the hype.

What we have to do is try, this time, to not drop the ball. CSS is part of making the browser environment a fully-fledged operating system, which means vastly increased complexity for the web page over the static text-based document of a decade ago. There will be decisions made about technology and support for screenreader users of these pages a-plenty: don’t leave them until the application is finished, because it never will be. The web moves too fast. Investigate HTML5 and WEB-ARIA and using your site without a screen or a mouse or the ability to click-and-drag.

Finally, coming full-circle back to our layout TABLES: if you want to help screenreader users, don’t waste your time replacing TABLE layouts with CSS. Wait until HTML5, and add the existing useful page semantics in HTML4, especially for your data tables. And make you funky AJAX sites work somehow if you turn off Javascript and pull out your mouse, and you’ll be doing the Right Thing.