@media - High-Noon Shoot Out: Design vs Implementation

This was a bit of light-hearted fun, with two heavyweights standing in opposing corners and trying to convince us their point of view was right.

[the protagonists on the podium]

In The Design Corner - Mr Simon Collison
The Design Manifesto went thus:

• Visual design is not complex engineering
• Design interfaces visually, don't be afraid to take risks
• Reserve the right to veto decisions of technologists
• Think, build & design organically
• Don't pander to personal prefereneces
• Deliver a rich, considered visual experience for all
• Be expressive with web typography
• Layout decisions are the preserve of the designer
• Visual design makes the first impression - respect it!
• Build everything in Flash (not really)

[Evil Drew - New Implementation, New Danger!]

In The Implementation Corner - Mr Drew McLellan
It all started with nxoc01.cern.ch, the very first web server. Drew said we were all implementers, and as such, we needed to know our enemies:

• Fixed width layouts
• Flash for non-media presentation
• (Flash breaks the basic nature of the web when used for anything other than a player for graphics or audio, and each Flash player instance impacts on performance of the browser)
• Text replacement, since text on a web page is a solved problem
• Styled form elements
• Potent GETs
• Controlled heights
• Controlled text size
• Colour schemes and low contrast
• The user agent
• The FOLD - THERE IS NO FOLD since we never know where it's going to be from one browser/user to the next!!

[Drew gets all fervant and placard-wavey saying There Is No Fold]

Conclusion
Of course, we all know that life's not so black and white, and at different times, we may have to sit in different camps. So it was a nice way of stimulating some light-hearted debate, but there's definitely no "right" answer on this one!

WSG London #3 - Accessibility

I'm playing catch-up a bit with blogging. I was at the third London Web Standards meeting on 28th February, which had an Accessibility theme.

We had three very different talks, each highly informative and enjoyable.

Niqui Merret on Accessbile Flash
Niqui started out by saying that Flash and accessibility don't have to be mutually exclusive, as many people presume. However, in the real world:

No single technology can be 100% accessible to all users. Aim to achieve the most accessible solution possible.

It's up to developers, programmers and copywriters to make sure their contributions are as accessible as possible. It's also up to the software vendors (eg of screen readers) to try and implement the standards properly and as quickly as possible. She also mentioned FlashAid (talks to screen reader and turns off the Javascript/Ajax so browser sees alternative accessible content) and SWFFix (a tool for progressive enhancement) as useful resources for Flash developers.

She talked a bit about the Accessibility panel in the Flash authoring environment, which allows developers to set things like Tab order and ALT text. And she demonstrated a fun little game in Flash, which was fully accessible without mouse and to screenreaders:

[Niqui demonstrates her accessible Flash game]

Ann McMeekin on Accessibility - What Not To Do
Ann is a Web Accessibility Consultant for the RNIB, and clearly knew her subject inside out.

She made many excellent points, but some of the most salient were:

• Don't assume all users with disabilities are the same
• Don't ignore users who come to you with a problem
• Don't forget to set your page's default colours - background and foreground (if not, changing Windows default colour scheme could have a dramatic effect)
• Don't waffle - be clear and concise, don't repeat yourself
• Just because you can add a title attribute to almost anything, doesn't mean you should - it's largely redundant if your link text is descriptive enough
• Don't be shy - show skiplinks, and use :focus and :active as well as :hover
• Put instructions before forms - otherwise someone who has zoomed the page (magnified) doesn't have a hope in hell of seeing what the labels are

One of the most surprising things was to learn that most screen readers will read out the legend to an accompanying fieldset before every label in the fieldset - so it's important to keep legends short and concise, and so they will make sense when read with the form field label.

[right, Ann in full flow]

Two final thoughts from Ann:

• Don't jump on the bandwagon and implement the latest cool widget without knowing what impact this might have on your users
• Accessibility doesn't mean you can't be creative

Mike Davies on Web Accessibility - The Developer's Tale
Mike's talk was a case study of the re-design of Legal & General's website services and applications, which he had been heavily involved with before his move to Yahoo! in the summer of 2006.

Four years ago, before the project started, L&G's website was ranked 92nd in a FTSE100 survey of websites; it ranked badly with search engines, had at least 150 links on every page and was horribly inaccessible. Through the vision of the website manager, the site was completely redesigned with accessibility at the heart of the thinking.

They reaped the benefits very quickly:

• 40% increase in website traffic
• doubled conversion rates (that is, number of people completing an online application for insurance etc, versus those who start the process)
• doubled online revenue
• cut maintenance costs by two thirds
• increased natural search-engine traffic by 50%
• paid for itself in five months

[conversion rates for Home Insurance - lilac = old site, burgundy = new site. The first two bars are the numbers starting the process, middle represents those finishing a quote and last pair are numbers of completed applications]

And the website is now held up as a highly-regarded example of how to do things properly - it is a PAS 78 and AccessibilityNet case study, has accreditation from the Shaw Trust, and is cited in books on accessibility.

Thanks again to Stuart for organising an excellent event. I look forward to the next one.

Playpen #6 - sIFR Headlines

I've been meaning to experiment with sIFR headline styling ever since hearing Dave Shea's Fine Typography On The Web piece during the @media 2006 conference. I've finally got a demo going at playpen #6.

What does sIFR mean?
sIFR stands for Scalable Inline Flash Replacement, and is an unobtrusive JavaScript/Flash solution for providing lovely fonts on your site (eg for headlines) whilst still remaining accessible, and not relying on that font being installed on a user's machine. Read more about the techniqute by visitng the official sIFR Wiki/Documentation site. H1 and H2 headings are best restyled using sIFR, rather than large bodies of text. If a browser does not have JavaScript enabled, the headlines will just be styled by the regular CSS definitions, so it degrades gracefully.

Why Bother?
There are several techniques for image replacement. The Gilder/Levin method is one such (see Dave Shea's article which explains some of the others too). Gilder/Levin is recognised as one of the best from an accessibility standpoint. But the down side, is that you have to manually generate each graphic used to replace your text, plus add a specific CSS rule for each in your stylesheet. That's all very well if you have a smallish, static site, and not many headings to replace. But what about database-driven sites and blogs, where you don't know in advance what the text will be which needs replacing? The only practical way to go is sIFR under these circumstances.

Where Can I Get It?
More information and a download for the code can be found at Mike Davidson's sIFR page.

Where Is It Used?
Keep an eye out for any sites which use unusual typography for headings or recurrent elements. If this is a database-driven site (such as ecommerce or blog), the chances are, sIFR will be the method that's used. Two likely candidates off the top of my head are:

• iPod411.com
• Bobble's Blog (it's not all about cup cakes)

d.construct, Mash My Flex Up

A presentation by Aral Balkan

Poor old Aral drew the short straw and was in the "graveyard shift" straight after lunch. I think he got us all on his side straight away by holding his hands up and coming clean:

["Don't shoot me, I'm a Flash developer!"]

Now I must confess that I'm no Flash guru. I have built one site with Flash5 (it was a long time ago!) and did a minimal amount of ActionScripting for that, but Aral's knowledge and experience was way beyond mine! So I didn't take too many notes, I just tried to watch and keep up :-)

• He gave a quick overview of Flex 2
• Lets you declaratively design iterfaces by using MXML
• MXML is XML
• Scripting uses ActionScript3 (which is ECMAScript4)
• Looks like Java, smells like Ruby
• AS3 is optionally typed, and a dynamic language
• Compile MXML and AS3 to SWF bitecode
• Each MXML tag represents an AS3 class
• SWF bytecode executes in the Flash Player which is a virtual machine
• Flex2 SDK is cross-platform and free
• FlexBuilder2 is a visaul IDE based on Eclipse, costing ~£370
• There's Flex Data Services and Server
• RPC and real-time communication, video and audio streaming
• There are also open source alternatives like Red5, AMFPHP and openAMF

Styling is applied with CSS. Data can be consumed via the following formats:

• REST (see previous blog post)
• XML-RPC
• SOAP
• JSON
• Flash Remoting (= binary JSON)
  

For more information, see Aral's website and download his presentation.

@media, Beyond A Code Audit

Accessibility is about more than just making sure you have passed the code audit points in WCAG, said Robin Christopherson of abilitynet.org.uk

Useful Test Tools/Tips:
Home Page Reader (text only) - cheaper than JAWS.
Natural Language - if you switch language mid-paragraph, use the Inline Language Tag to flag it so that screenreaders know how to correctly interpret the change for pronunciation.
Always define background and foreground colours by default, you can never assume they will be black and white (say).
textaloud.com is a text-to-speach engine.

Problems with FLASH
Dynamic content is difficult to make accessible in Flash. For instance, ALT text should exactly match the words shown in an image or Voice Recognition Software doesn't work properly. Flash breaks the Say What You See rule.
The Flash Accessibility presentation at macromedia.com is totally aural with no text transcript => breaks one rule of accessibility straight away! No tool tips on any of the Flash buttons. Dynamic content requires a screen refresh otherwise screen readers are not aware that content has changed (one of the big problems with some emerging Web2.0 apps). Presentation is low contrast - which would probably fail the Vischeck criteria.
Flash content is never as accessible as HTML (and by inference to search engines also). Robin (blind) did not find it easy to use Flash presentations as he was never sure if he was missing something. Also for partially sighted people, you can't change the font style or colours in a Flash movie.

Problems with Javascript
JS can be a nightmare when its used to provide main functionality for a site - it's sometimes not enough just to produce a no-JS version of a page if you're relying on it to accomplish something fundamental. Non-JS versions of a page need to be flagged as available as Home Page Reader is a plugin to the IE engine, and therefore the user agent could well have JS enabled.
Using a Javascript routine to update the time displayed on a page every second can cause havoc - the screen reader has barely had time to read out the nav links before the page is declared to have been refreshed and it all starts again from the top - you get stuck in an infinite loop and can never get out!

Problems with Colour / Whitespace / Text Alignment
Never use colour solely to convey meaning - The Tube Map fails the colourblind tests!
People with congnitive disabilitities can have big problems if enough white space is not provided - don't crowd things together. Use the tags to define abbreviations, plus a decent-sized sans-serif font.
Folks with Dyslexia have trouble reading fully justified text due to the uneven word spacing - left justified text is much better for them.

Assistive Technologies and their special requirements:
Headset mouse emulator - fine control of movement can be limited - don't make links too close together like lastminute.com. Google's Next page links have good spacing.
On-screen keybord - takes up valuable screen real estate
Suck/Blow tube for left/right mouse click - again, can make movements clumsier than with a mouse alone
Screen Magnifiers - disney.com was a nightmare to view with a magnified screen because of the lack of proper TAB order - the cursor went all over the place, often out of the immediate viewport of the magnified screen. Users get lost.
Screen readers - IE7 is not good with these at present.
No Mouse - tab order is vital - take a look at the Vatican's site to see what a screwed up tab order can do :-(
Also, Tab Focus can be tricky to distinguish - some sort of obvious highlights work best..
Skip Nav Links - when they get focus they can have unhide set on them with CSS which is quite neat.