Earlier this year Jakob Neilson said that the the mobile web 2009 mirrors the desktop web 1998 highlighting how hard it is to browse on a mobile. He’s right of course, mobile browsing can be frustrating and tiresome at the best of times. His solution however is to design not just ‘different websites’ for desktop and mobile but in the case of ‘moderately rich sites’ build ‘two mobile designs: one for low-end cellphones and another for smartphones and big-screen phones’.

Sound like unnecessary hard work? I think so. It also hints at repeating the mistakes of desktop web design circa 1998 where we thought the answer was to design for one browser, use proprietary technology, build text only websites for disabled users…the list goes on.

So let’s not make that same mistake and instead fast forward to one of the principles of good web design that dug us out of the dark hole of 1998: progressive enhancement. Add to that one of the biggest problems we face on mobile today, varying viewport sizes, and we have a good case for one website fits all.

Accommodating the multitude of different screen sizes is tricky and unpredictable. Mobile browsers try to work around this by offering a desktop view (which renders the whole site and is zoomable) and a mobile view (where content is rendered as a single column with some CSS stripped out). You can try this for yourself using the Opera Mini Emulator or looking at the screen shots below.

The image above shows this site as seen in desktop mode on Opera Mini. The square on the top left can be activated (using either a keypad or touch screen phone)  so that the area within the square is scaled up to fill the viewport.

This second image shows my site rendered as a single column of content. Some of the CSS has been stripped out so that there is basic styling and limited images. Note: screen shots were taken using an emulator for Opera Mini 4.2 which doesn’t have as good CSS support as Opera Min 5 beta.

As a developer you should never rely on the mobile browser to fix content rendering problems that arise from design so you need to find ways to accommodate varying viewport sizes yourself using techniques such as CSS 2.1 media types.

Media types are style sheets or styles tailored for different media such as ‘print’, ‘screen’, ‘aural’, ‘braille’, ‘handheld’, ‘print’, ‘projection’, ‘screen’, ‘tty’, ‘tv’, and ‘all’. You’ll notice that not only do these include special outputs for handheld and mobile devices but also braille and tty making them a handy accessibility tool too.

Media types can be easily added using stylesheets as follows:

<link rel="stylesheet" type="text/css" media="screen" href="sans-serif.css">
<link rel="stylesheet" type="text/css" media="print" href="serif.css">


Alternatively you can declare that sections of your CSS apply to certain media types within existing stylesheets using @media:

@media print {
body { font-size: 10pt }
}
@media screen {
body { font-size: 13px }
}
@media screen, print {
body { line-height: 1.2 }
]

So far so good as Mobile Web Best Practices 1.0 recommends media types in their default delivery context – a base set of design guidelines for mobile. They also state you shouldn’t develop to only the DDC specification – and therefore limit design to the capabilities of low end phones – but adapt content to exploit the capabilities of higher end devices that can handle more robust styling and technologies.

Sound familiar? Step in progressive enhancement and CSS 3 media queries.

Media queries extend media types by using features such as ‘width’, ‘height’, ‘device-width’, ‘device-height’, ‘orientation’, ‘aspect-ratio’, ‘device-aspect-ratio’, ‘color’, ‘color-index’, ‘monochrome’, ‘resolution’, ‘scan’, and ‘grid’.

In short you get more for your money than you do with media types as you can specify things such as screen width that can target a style sheet to only apply to a screen which is 480px or less as shown in the example below:

@media screen and (max-device-width: 480px) {
// insert CSS rules here
}

You can check out a working example of media queries here (just resize the window to see content reflow) and read a write up of how it is done in the optimizing for mobile section of a developer’s look at Opera Mini 5 beta.

Media queries are still being adopted by desktop and mobile browsers alike with support at the time of writing as follows (as far as I could see): Opera Mobile, Opera Mini 4, Opera on the Nintendo Wii, iPhone, Bolt, Iris and the Nokia s60 browser.

Within that the full set of media query features may or may not be supported by any one browser however I would expect the key ones are such as  ’width’, ‘height’, ‘device-width’ and ‘device-height’ to be included. I’ve not been able to track down any up-to-date information here so let me know if you do.

The principles of good web design still seem to hold true when it comes to designing for mobile and we’d do well to learn from some of the mistakes from desktop rather than repeat them. Happily this makes our jobs a bit easier as the same rules apply:

• Set your baseline of supported web technologies
• Use web standards: HTML, CSS, JavaScript, XHTML etc
• Apply progressive enhancement
• Test, test, test

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

Details, details…

W3C is running an extended and improved version of its online course to introduce Web developers and designers to its Mobile Web Best Practices.

In this course you will:
* learn about the specific promises and challenges of the mobile
platform;
* learn how to use W3C’s Mobile Web Best Practices to design mobile-friendly Web content and to adapt existing content for mobile;
* discover the relevant W3C resources for mobile Web design.

As a participant, you will have access to lectures and assignments that provide hands-on practical experience of using W3C’s mobile Web Best Practices. You will have direct access to W3C experts on this topic who are the instructors for this course, and you’ll be able to discuss and share experiences with your peers who are faced with the challenges of mobile Web design.

Visit An Introduction to W3C’s Mobile Web Best Practices for more information including details of the course material, more about who will benefit most from the course, the registration fee and access to a free sample of the course itself.

Background reading and useful links

• Mobile Web Best Practices 1.0, W3C.
• Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices, W3C.
• Designing and Developing mobile web sites in the real world, part 1 by Brian Suda.
• Designing and Developing mobile web sites in the real world, part 1, By Brian Suda.
• How to serve the right content to mobiles, by Chris Mills.

Working for Opera I’ve just joined the UAAG Working Group and have started to look at the guidelines properly for the first time in ages. This is not my natural area as I’m a content person through and though and therefore much more familiar with the Web Content Accessibility Guidelines (WCAG). So it’s got me thinking would a developer, a website owner, a user or a software procurement person really want to get their hands dirty with UAAG?

So this is what I came up with that made sense to me:

1. You develop accessible content. UAAG is just one of three sets of guidelines relating to accessibility produced by the W3C the other two being the “celebrity” Web Content Accessibility Guidelines (WCAG) and the more “D-List” (but up and coming thanks to social networking) Authoring Tool Accessibility Guidelines (ATAG). All share interdependencies and are designed to work together so that browsers (UAAG) render content (WCAG) that has been authored and tested (ATAG) for accessibility.
   If one component is weak it can result in your content (that you have made accessible according to WCAG say) unusable. Think for example of the amount of times you hear “But this browser works differently from that browser” or “screen readers haven’t caught up yet and can’t handle such and such”. As a developer you have to spend more time developing workarounds to compensate for the browser and/or assistive technology. Not something that anyone relishes.
2. You’re interested in developments with HTML5. With so much discussion around what is relevant to the browser implementors and authors it’s useful to see where the lines blur between browsers and authors. HTML5 is attempting to do much that the author has had to do themselves before such as forms validation, support for video and audio, datagrids and so on. Previously these would be done by the authors using scripts meaning more work and less consistency for the user across websites. This is turn leads to a wider margin for error to allow inaccessible content and poor usability.
3. You build plugins or extensions. According to the UAAG FAQ these too are also user agents and therefore have to follow the principles of keyboard access, rendering content accessibly and communicating with assistive technologies. So if you’re into building extensions for Firefox then you’ll need to ensure accessibility.
4. You develop web applications. Ok, so this is more of a controversial one but there’s nothing wrong with that. I’m also curious to hear what people think. So here’s the question: when does web content morph into being a web application and become better defined as a user agent rather than web content? For example, Easy YouTube is a skin for YouTube designed to make playing video easier for people with cognitive problems. As such it can also be defined as a media player which sits very much under the user agent definition.
   This is a tricky because it’s doubtful that any developer is going to seriously look at following both WCAG and UAAG when developing. You can also argue that if you were able to upload, and therefore author, content to Easy YouTube the developer could find themselves having to reference UAAG, WCAG and ATAG.
   Back in the real world I think this is asking way too much but there is something of a cross over. It may be that WCAG is sufficient covering key aspects such as device independence and keyboard access but understanding the relationship would be useful. I wonder if anyone has done a mapping of UAAG, WCAG or ATAG…
   The UAAG working draft does specifically ask what people’s thoughts are on web applications:

   “Does the inclusion of Web applications (e.g video players, email clients, document applications) in the definition of user agents add undo burden or conflicts? What distinguishes Web application user agents from Web applications that are not user agents?”

   So leave a comment if you have any thoughts.

5. You’re a user. Being a user of assistive technology I would be keen to ensure that content worked for me. Understanding all three sets of guidelines means you’ve got a better idea of why something doesn’t work and how it can be fixed. This will help you to both flag problems to the vendors of user agents as well as inform decision as to which browser, media player and assistive technology you use.
6. You’re in procurement. If you are someone who makes decisions about what software to purchase you’ll need to know which software meets you accessibility requirements. Being able to do a comparison against UAAG, or to be able to ask for compliance to UAAG in tenders can help safeguard accessibility concerns.

So I’m sure you’re all convinced that you need to look at UAAG right away so I wont hold you back with any more chatter from me. Details about how you can comment on UAAG are available from W3C together with an overview of UAAG and the draft UAAG 2.0 in all its glory.

This is all well and good if your native language is English but can become a quagmire of tech talk and mumbo jumbo if not. Thankfully, as Richard Ishida lead of the Internationalisation Group pointed out to me today, those nice chaps at W3C have a fair amount of their work already translated and available for you to search using their nifty little  translation search tool.

It may not look pretty but it lets you search by language, topic, translator and translation dates. Here you’ll find lots of resources covering internationalisation, accessibility, tutorials and much more.