Education is core to getting the web to pull it’s socks up and become more of an inclusive, cross browser, cross platform, cross device place. By creating a curriculum and web craft degree backed by both industry and educators, the Open Web Education Alliance (OWEA) hopes to help produce the graduates that employers need to build slick, usable, accessible and profitable websites.

Up to this point all the work in OWEA and WaSP InterAct has been voluntary contributed to by some of the best web designers and developers out there today. To get this initiative really off the ground however we need to put in some serious hours and to do that OWEA needs funding. (Disclaimer: I’m hoping to be the one to put in the serious hours).

This is where you come in

We’re applying for a grant from the Shuttleworth Foundation and would love to show them how well backed this initiative is by our community. So, if you care about a sustainable web then take two minutes to show your support by signing up to  The Open Web Education Alliance project funding bid. We need comments, contributors and votes!

Buy the book

WaSP InterAct have just brought out Interact with Web Standards: A Holistic Approach to Web Design - over 500 pages of hotness by Erin Anderson, Virginia DeBolt, Derek Featherstone, Lars Gunther, Denise R. Jacobs, Leslie Jensen-Inman, Chris Mills, Christopher Schmitt, Glenda Sims, Aarron Walter. Well worth a read for anyone learning or teaching web design.

While you’re at it you may also want to get Introducing HTML 5 by Bruce Lawson and Remy Sharp. It’s out in July so it’ll be a nice little surprise when it drops through the letter box in a months time.

The issue

Plugin support typically needs an API that acts as a doorway connecting the plugin, browser and user. IE gets round this by using ActiveX – itself a closed propitiatory format – so users can tab into and out of the Flash. Of course keyboard access within the Flash content itself is handled by Adobe and is now considered to be keyboard accessible. So it’s really support for entering and leaving the plug-in with keyboard that is the issue.

The browser fix

Ideally there needs to be a standardized API that can be used across industry to enable plugin support across browsers. The most common  API is Netscape Plugin Application Programming Interface (NPAPA). First developed for Netscape it has subsequently been implemented in other browsers including Opera, Safari, Firefox, Konqueror, Google Chrome, and some versions of Microsoft Internet Explorer.

The kind of access NPAPI supports includes scripting, printing, full screen plugins, windowless plugins and content streaming but is not as powerful as ActiveX, and is still evolving – in particular tabbing into and out of the Flash movie.

Help is at hand however.

There is currently a proposal to solve the issue of Flash support being lead by Mozilla, Adobe, Opera, Apple, IBM and Sun which has now been accepted. Implementation will depend on collaboration between all stakeholders including plugin vendors and of course Adobe.

Aside from the the plugin API solution is there an alternative quick fix for Flash support in Opera?

There have been some discussions internally but it seems there is no quick fix that will completely, and satisfactorily, address the issue. There are two ways that NPAPI plugins can work. The first (default) is called “windowed”. This is essentially an OS window rendered on top of the browser. Keyboard input is therefore direct and not via the browser.

There are a couple of drawbacks with “windowed” however. Firstly it can pose security issues. Secondly it’s not a complete keyboard access solution because while getting focus into the plugin is possible getting focus out is not. This is key and really negates the point of being able to tab into the Flash Player because as a keyboard only user you’ll only get stuck there.

The second mode is called “windowless”, where the browser controls more of the plugin rendering. Here keyboard input goes via the browser (possibly depending on OS) and in turn is intercepted. The drawback with this solution is that real world support is limited as most plugins do not support this mode, and for those who do it’s not that widely used due to performance issues.

By far the best and most secure solution is standardising the NPAPI API so that it works across browsers with all plugins. Better not just for Opera but the web in general.

In terms of a solution for Opera it seems the fixes available now fall far short of what we would want to give our users. The good news however is that to implement support once the plugin API is ready should be fairly straight forward.

The developer fix

So where does this leave you as a developer, and more importantly your users? There is a hack you can use to give Flash keyboard access using a method in your Flash movie to focus a chosen element. You can then create a text link that calls this method to “skip into Flash”. This isn’t something I’ve tried and tested and I’d be interested to hear comments from anyone who has.

Update –  As Andrew Kirkpatrick points out there is another way to give Flash focus using the SWFFocus class. While the technique showcased discusses this in the context of Firefox I did a quick test in Opera 10 Beta and Safari 4 but had no luck accessing the content.

But I suppose the real question is why hack what you can already do using existing technologies supported across all browsers? Don’t get me wrong, I like Flash and have two thumbs up at Adobe for the work they have done to make it accessible, but if I’m building a site using Flash and knowingly locking out all non-IE users then I can’t use it.

As Christian Heilmann points out much of what Flash does can be done with existing technologies supported in the browser:

Using the DOM and JavaScript I can create HTML elements that work with all kind of assistive technology. Instead of hoping that keyboard users can access my Flash content I use what browsers already have – links, buttons and form fields – to interact with the it.

WAI-ARIA is also a core way to build screen reader accessible and tabbable web apps and widgets. Added to this the HTML5 <video> element will soon give us native support for video across browsers; something that Flash is used for extensively today.

So there are ways and means now to avoid the keyboard trap that Flash content poses for keyboard only users plus there is work to provide a universal solution in the form of the proposed plugin API. But for now I’d personally always opt for the standards based cross browser solution so as to ensure happy users and avoid additional work and hacks.

Aside from a minor glitch in the middle when I seem to disappear altogether it was a fun interview (despite Nav swatting wasps when he was on mute and my having to throw stuffed toys at the dog to stop her snoring).

Big thanks to Dirk Ginader and Sascha Postner for having us on. Links mentioned in the interview are:

• Opera Unite – share files by running a server from the comfort of the browser.
• Opera Developer Network – articles, blog posts, tools, tips and resources for developers.
• ODIN blog – news, views and presentations from the Opera Developer Network.
• Opera Labs – a showcase of technologies for tomorrow.
• Opera Web Standards Curriculum – tutorials in standards-based Web design, including HTML, CSS, and JavaScript development.

• Web网站标准的简史以及对使用者的好处 – Simplified Chinese
• Web網站標準的簡史以及對使用者的好處 – traditional Chinese
• Τα web standards και η χρησιμότητά τους – Greek.

You can find more translations by Samuel of web standards articles in Chinese in the web standards translation page on WaSP as well as over 30 other translations (and counting).

If you have a translation you want to add to WaSP drop me an email at email the ILG Co-leads

The W3C describes SVG is a relatively simple way to generate graphics on a web page using markup:

SVG is a platform for two-dimensional graphics. It has two parts: an XML-based file format and a programming API for graphical applications. Key features include shapes, text and embedded raster graphics, with many different painting styles. It supports scripting through languages such as ECMAScript and has comprehensive support for animation.

SVG is supported in all modern browsers – with the exception of Internet Explorer – including most mobile browsers making it an excellent cross platform bit of bling. Even the lack of support in IE could be addressed soon not by Microsoft itself but by Google who are billed to give a keynote at the SVG Open in October on their SVG for IE drop-in library. This could boost the popularity of SVG given that to date IE has been one of the biggest things holding it back.

Update 22 August 2009: Announcement about Google’s 60K library to bring SVG, SMIL, video, audio to IE.

The real bonus of SVG however is it’s scalability, integration with web standards, re-usability and ability to manipulate objects all of which lend SVG to being a robust – and crucially – accessible alternative to other image based formats such as GIF, PNG or JPEG.

SVG graphics can be scaled and resized without any of the blurring or pixellation that you see on traditional images. Scaling is important to users with low vision who enlarge text in the browser or rely on assistive technologies such as tactile graphic devices (which typically have a very low resolution) and screen magnifiers. So if you want to have images of text as headings and not worry about these becoming blurred and unreadable you can. As the image below shows, the enlarged PNG is pixellated whereas the SVG equivalent is smooth and crisp.

Comparison of PNG and SVG enlargements taken from Accessibility Features of SVG by Charles McCathieNevile and Marja-Riitta Koivunen

XML, being a text based language, also lends SVG to better accessibility than current headline grabbers such as HTML5 canvas which lacks an accessibility API or hooks for screen readers. While the WHAT-WG currently recommend a fallback – a draconian circa 1999 HTML alternative that confines screen reader users to a disability ghetto – they are working on a “built in” rather than “bolt on” approach asking for input from the accessibility community for viable solutions to make canvas accessible. Bruce Lawson has the lowdown on SVG versus canvas in his post  Canvas, accessibility and SVG.

SVG and screen readers

While SVG supports many of the accessibility guidelines that we see in WCAG 2.0 and is supported by all modern browsers except IE, there is one drawback: screen readers do not handle SVG well.

It’s hard to say why. As Bruce Lawson pointed out it may be because “big screen readers have traditionally sat on top of Internet Explorer”. I think it may also be because screen reader vendors have an awful lot to keep abreast of out there with regards to browser compatibility, emerging technologies such as ARIA, developments in HTML5 as well as compatibility with software such as MS Office, Open Office, Flash, PDF etc. Google’s promise of fixing SVG in IE should have some positive knock on effects – or at least let’s hope.

Screen readers not being able to handle SVG well is no reason to not make your SVG screen reader ready however. As always you want to be thinking about future proofing so as to avoid any pesky and costly retrofits at a later date.

Title and descriptions

The title and desc elements can be added to any graphic to provide a fallback for screen readers. These can be added to parts of the graphic – hierarchically – or the graphic as a whole. Both title and desc can be used together with the former acting as the title of the graphic and the latter as as expanded explanation (from what I’ve understood anyway). If the image above of the tigers was created in SVG you’d code it as follows:

<?xml version="1.0"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000802//EN" "http://www.w3.org/TR/2000/CR-SVG-20000802/DTD/svg-20000802.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450"
xmlns="http://www.w3.org/2000/svg"  xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Tiger's head</title> <desc>A slinky SVG tiger</desc>
........
</svg>

According to the spec however the title element in SVG may behave a little differently to how the title attribute behaves in HTML:

Each container element or graphics element in an SVG drawing can supply a ‘desc’ and/or a ‘title’ description string where the description is text-only. When the current SVG document fragment is rendered as SVG on visual media, ‘desc’ and ‘title’ elements are not rendered as part of the graphics. User agents may, however, for example, display the ‘title’ element as a tooltip, as the pointing device moves over particular elements. Alternate presentations are possible, both visual and aural, which display the ‘desc’ and ‘title’ elements but do not display ‘path’ elements or other graphics elements. This is readily achieved by using a different (perhaps user) style sheet. For deep hierarchies, and for following ‘use’ element references, it is sometimes desirable to allow the user to control how deep they drill down into descriptive text.

While desc is not displayed (in accordance to the spec) it is up to the browser to decide how to render the  title element in SVG. In other words it can either be displayed as a ‘tooltip’ or not. Using Opera 10 Beta 2  title is shown as a ‘tooltip’, but neither Safari 4.01 Firefox 3 display the ‘tooltip’.

The closet match to the behavior of the title attribute in HTML in SVG is xlink:title.

The title attribute shall be used to describe the meaning of a link or resource in a human-readable fashion, along the same lines as the role or arcrole attribute. A value is optional; if a value is supplied, it shall contain a string that describes the resource. In general it is preferable to use a ‘title’ child element rather than a ‘title’ attribute. The use of this information is highly dependent on the type of processing being done. It may be used, for example, to make titles available to applications used by visually impaired users, or to create a table of links, or to present help text that appears when a user lets a mouse pointer hover over a starting resource.

A link with a title attribute in HTML would look like this:

<a href="http://www.mysite.com" title="My super funky site">visit my site</a>

Where as a link in SVG would look like this:

<a xlink:href="http://www.mysite.com" xlink:title="My super funky site"><text x="20" y="20">visit my site</text></a>

In the above the x and y value are the co-ordinates where the text is placed on the canvas. To ensure this works you have to declare the XLink namespace in the document, most commonly in the SVG root element.

One important thing to note is that the ‘a’ element can be wrapped around elements in SVG, a little like block level linking in HTML5. This is a great feature as it allows for a larger clickable area for those that need it and you can wrap as many components in the link – let’s say a graphic with accompanying text – as you like.

Hierarchy

Just as you would give an HTML page a hierarchical order the same is true of SVG. This allows a non-sighted user to build a mental map of the graphic and is founded on WCAG 1.3.2 Meaningful sequence.

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)

Expanding on the tiger image above and adding in all four images into one would mean the code looked as follows:

<?xml version="1.0"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000802//EN" "http://www.w3.org/TR/2000/CR-SVG-20000802/DTD/svg-20000802.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450"
xmlns="http://www.w3.org/2000/svg"  xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Tigers</title> <desc>Drab PNG tigers and slinky SVG tigers</desc>
<!-- add graphic content here, and so on for the other components-->
<g id="Tigera"> <title>Tiger A</title> <desc>A small tiger  using PNG</desc> </g>
<g id="Tigerb"> <title>Tiger B</title> <desc>A small tiger using PNG</desc> </g>
<g id="Tigerc"> <title>Tiger C</title> <desc>A large tiger using PNG</desc> </g>
<g id="Tigerd"> <title>Tiger D</title> <desc>A large tiger using SVG</desc> </g>
</svg>

You’ll notice in the above that the ‘g’ element is used to structure the document.  This is basically a container element that is used to group related graphics. ‘g’ elements can also appear within ‘g’ elements.

Grouping constructs, when used in conjunction with the ‘desc’ and ‘title’ elements, provide information about document structure and semantics. Documents that are rich in structure may be rendered graphically, as speech, or as braille, and thus promote accessibility.

Colour

The basic rule of accessible colour apply to SVG just as they would any other image. In other words don’t rely on colour alone to convey meaning or use colour that lacks contrast. This falls in line with WCAG 2.0:

1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)

and

1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

Mark up and CSS

Again familiar rules that apply to HTML and CSS also apply to SVG:

• Ensure your SVG validates to SVG RelaxNG grammar however some discussions suggest to do so without the doctype.
• Separate structure from presentation.
• Use text for text and not graphics.
• Provide as much structure and alternatives as possible using the g, title and desc.
• Style text using fonts not images.
• Use ‘xml:lang‘ to identify the natural language of content and changes in natural language. This ensures that textual content can be spell-checked, or converted to speech.

WAI-ARIA

ARIA describes how to add semantics and other metadata to HTML content in order to make user interface controls and dynamic content more accessible. In principle this is also applicable SVG and as such SVG 1.2 recommends ARIA for adding in accessibility hooks for screen readers via the ‘role’ attribute.

The ‘role’ attribute assigns one or more role values to an element which in turn can get fed back to a screen reader. ARIA 1.0 is currently in Last Call (the stage before it becomes a W3C Recommendation) and is expected to be published soon. While the SVG 1.2 specification recommends using roles, ARIA 1.0 itself is not massively focused on SVG. According to the Protocols and Formats Working Group however SVG will feature more in ARIA 2.0 (along with extensibility, live regions and HTML5 support).  Erik Dahlstrom, co-chair of the SVG Working Group, has provided feedback around SVG and ARIA including comments on managing focus, accessible name calculation,  navigation and more.

While it is clear there is a lot of work to be done the fact that ARIA roles can be used is a positive step forward as it acts as a bridge where screen reader support falls short.  Jaws, WindowEyes, NVDA, FireVox and Orca are all adding support for ARIA as is IE, FireVox, Opera and Safari (Codetalks has a list of who supports ARIA) so if thinking about adding ARIA to your SVG now is clearly a wise move.

So just how accessible is SVG?

Clearly a lot of work needs to be done to get SVG accessibility ready for screen readers. Some hooks are there however the real work is yet to come both from screen reader vendors as well as the specification writers. What’s reassuring is that both the ARIA and SVG camps recognise this and there is talk of SVG having a bigger focus in ARIA 2.0.

Putting screen readers aside there are clear benefits to SVG for screen magnification users with it being scalable, standards compliant and able to provide block level linking. The standards aspect of this is important as it means that you can use XSLT to transform SVG into HTML – readable by all assistive technology.

Accessible SVG has a potential – despite it being early days – as a useful alternative for canvas and other image formats. Who knows, with possible IE support on the horizon and more of a focus in Aria 2.0 perhaps screen reader vendors will step up efforts to support SVG. If they do as have a really robust technology out there to add to the developers toolbox.

For more check out:

• David Storey, Doug Schepers and Mathew Smith on Twitter.
• Accessibility features of SVG Charles McCathieNevile and Marja-Riitta Koivunen.
• Scalable Vector Graphics (SVG) Tiny 1.2 Specification from the W3C.
• Inkscape – an Open Source vector graphics editor, with capabilities similar to Illustrator, CorelDraw, or Xara X, using the W3C standard Scalable Vector Graphics (SVG) file format.
• Accessible Rich Internet Applications (WAI-ARIA) 1.0