One web and universal access: a bridge too far?

Written by Henny Swan. 1 comment

Henny Swan

Opera Web Evangelist Henny Swan has focused on accessibility and usability since the late 90's when she started out working for a Chinese search engine and her own start-up in China. Henny is a member of the Web Accessibility Initiative User Agent Accessibility Guidelines Working Group (UAWG) and co-lead of the Web Standards Project International Liason Working Group.

Can the idea of universal access really meet the needs of users with disabilities browsing on mobile and hand-held devices or is this just wishful thinking?

In a world were the web is every­where — in our pock­ets, on our TV’s, on games con­soles and more — you can’t risk shut­ting out users as we become more and more diverse. But mak­ing the web acces­si­ble to diverse users on mobile devices has its chal­lenges but it also has its advan­tages. Build­ing sep­a­rate ver­sions of sites means you can’t guar­an­tee cross device com­pat­i­bil­ity and you risk lock­ing out users.

In his arti­cle “Mobile Web 2009 = Desk­top Web 1998″ long-​​time usabil­ity spe­cial­ist Jakob Nielsen would have you believe that the idea of ‘one web’ is incom­pat­i­ble with uni­ver­sal access and the mobile web:

“Mobile phone users strug­gle might­ily to use web­sites, even on high-​​end devices. To solve the prob­lems, web­sites should pro­vide spe­cial mobile versions.”

In one regard Niel­son is right; brows­ing con­tent on a mobile or hand-​​held device brings a myr­iad of bar­ri­ers to access that are not such big issues on a desk­top, or don’t exist at all. Vary­ing view­port sizes, prob­lem­atic key­board input, walled gar­den plat­forms, poor script­ing and plu­gin sup­port all con­spire against the mobile user. A mobile user’s expe­ri­ence is not dis­sim­i­lar to that of the user with a dis­abil­ity on a desk­top com­puter. This in turn leads many design­ers to build plat­form or mobile spe­cific web­sites such as iPhone and .mobi, just as Nielsen suggests.

That brows­ing on mobiles and hand-​​helds is more dif­fi­cult is a fact. That design­ing sep­a­rate ver­sions to cater for the needs of users on hand-​​helds is, how­ever, ques­tion­able. To under­stand why let’s bring web acces­si­bil­ity into the equation.

The Web Acces­si­bil­ity Ini­tia­tive (WAI) from the World Wide Web Con­sor­tium draws par­al­lels between mak­ing a web­site acces­si­ble for peo­ple with dis­abil­i­ties and mak­ing it acces­si­ble for mobile devices. While there is no direct map­ping between the Web Con­tent Acces­si­bil­ity Guide­lines (WCAG) and Mobile Web Best Prac­tice (MWBP), there is a sig­nif­i­cant over­lap which means design­ing for mobile goes a long way to sup­port­ing users with dis­abil­i­ties and vice versa.

So far so good but this raises the ques­tion: if WCAG and MWBP are imple­mented will a web­site be both mobile ready and acces­si­ble to users with dis­abil­i­ties? This is where the equa­tion ceases to be quite so neat and tidy. One does not guar­an­tee the other just as build­ing a site strictly fol­low­ing WCAG will not always guar­an­tee it is usable by peo­ple with disabilities.

So what are the high­lights and cross overs between acces­si­ble and mobile web design? Are there poten­tial con­flicts of inter­est? And how fea­si­ble is it really to cre­ate web­sites which are uni­ver­sally acces­si­ble across devices using today’s technologies?

CSS

CSS is an obvi­ous can­di­date for sup­port­ing both acces­si­ble and mobile web design. Sep­a­rat­ing con­tent from pre­sen­ta­tion and flex­i­ble lay­outs are core to this. To accom­mo­date users with dif­fer­ent out­put media it is stan­dard to sup­port media types — style sheets or styles tai­lored for dif­fer­ent media such as ‘print’, ‘screen’, ‘aural’, ‘braille’, ‘hand­held’, ‘print’, ‘pro­jec­tion’, ‘screen’, ‘tty’, ‘tv’, and ‘all’ as defined in CSS 2.1. These can either be linked in sep­a­rate stylesheets or declared in sec­tions of a stylesheet using the @media attribute.

CSS 3 intro­duces “media queries” which extends the func­tion­al­ity of media types by allow­ing you to define what type of out­put devices a style sheet applies to using media fea­tures such as ‘width’, ‘height’, ‘device-​​width’, ‘device-​​height’, ‘ori­en­ta­tion’, ‘aspect-​​ratio’, ‘device-​​aspect-​​ratio’, ‘color’, ‘color-​​index’, ‘mono­chrome’, ‘res­o­lu­tion’, ‘scan’, and ‘grid’. The most fre­quently used are ‘width’, ‘height’, ‘device-​​width’, ‘device-​​height’ which are widely sup­ported while oth­ers have vary­ing sup­port across browsers. Using these, con­tent can be tai­lored to a spe­cific range of out­put devices and screen sizes with­out resort­ing to sep­a­rate ver­sions of your web­site for iPhone, .mobi and so on.

Media queries can be used in linked stylesheets or deliv­ered using the @import at rule or @media attribute. A typ­i­cal for­mat for the @media attribute is as follows:

  1. div {/*rule 1*/}
  2. @media pro­jec­tion {
  3.     div {/*rule 2*/}
  4. }
  5. @media all and (max-​​width: 800px) {
  6.     div {/*rule 3*/}
  7. }
  8. @media all and (max-​​width: 500px) {
  9.     div {/*rule 4*/}
  10. }
  11. @media all and (max-​​width: 350px) {
  12.     div {/*rule 5*/}
  13. }
  14. @media pro­jec­tion and (min-​​width: 1281px) and (max-​​width: 1600px) {
  15.     div {/*rule 6*/}
  16. }
  17. @media pro­jec­tion and (min-​​width: 1601px) {
  18.     div {/*rule 7*/}
  19. }

The above gives instruc­tions to the user agent on how to ren­der the page depend­ing on view­port size. Cur­rently sup­port for media queries on devices is still evolv­ing but does include Opera Mobile, Opera Mini 4, Opera on the Nin­tendo Wii, iPhone, Bolt, Iris and the Nokia s60 browser.

Device inde­pen­dence

Device inde­pen­dence aims to make — as far as is rea­son­able — the same infor­ma­tion and func­tion­al­ity avail­able to users irre­spec­tive of the device they are using. This does not mean that exactly the same infor­ma­tion is avail­able in exactly the same way, but impor­tantly, it is nev­er­the­less available.

A sta­ple of good web design is clear nav­i­ga­tion and never more so than for mobile web users and users with dis­abil­i­ties. Clearly described and unique links, well worded suc­cinct head­ings and well-​​written alter­na­tive text for images are all fun­da­men­tal to good navigation.

Occa­sion­ally how­ever, what may work on the desk­top to enable acces­si­bil­ity might work against users on dif­fer­ent devices. Using CSS to hide text that is intended to be invis­i­ble on screen yet avail­able to screen read­ers is a prime exam­ple of this. Often this is used for hid­den “new win­dow” warn­ings or for news sites that have a series of short sum­maries of sto­ries fol­lowed by a link that says “full story”. To hide text a CSS selec­tor rule is set as follows:

  1. a span { height: 1px; width: 1px; posi­tion: absolute; over­flow: hid­den; top: -10px; }

Then <span> is used with a link to hide text within the HTML:

  1. <p>How to cre­ate acces­si­ble and mobile ready web pages.
  2. <a href=”#”>
  3. <span>This explana­tory text is read by a screen reader but is not vis­i­ble onscreen</span>
  4. Full Story</a></p>

The ben­e­fit for a screen reader user is they hear the head­ing to the news item when they tab onto the link. This is impor­tant when you have many links to “Full story” on a page. On the other hand mobile users don’t get this infor­ma­tion which can result in costly down­load charges from seem­ingly small digres­sions click­ing on unclear links. This is espe­cially annoy­ing when you don’t get the new win­dow warn­ings as back but­tons don’t work.

Such vital nav­i­ga­tional infor­ma­tion can­not be com­mu­ni­cated via CSS alone and must instead be vis­i­ble text or icons to warn users of new win­dows. As a basic rule con­tent should always appear in the doc­u­ment object and be avail­able with CSS dis­abled. Text gen­er­ated via CSS is not part of the doc­u­ment source and is there­fore not avail­able to mobile users.

Pro­pri­etary ver­sus open technologies

Pro­pri­etary tech­nolo­gies such as Flash are a huge chal­lenge to uni­ver­sal access. Sup­port on mobile plat­forms as well as alter­nate devices such as the Wii is not robust.

To fur­ther exac­er­bate the prob­lem on the desk­top most mod­ern browsers aside from IE suf­fer from poor key­board sup­port of Flash. While Flash con­tent itself may be nav­i­ga­ble the Flash object can not be tabbed into or out of from the browser as there is no stan­dard­ized sup­port API for plu­g­ins. This is cur­rently being addressed by plu­gin ven­dors such as Adobe and browser makes such as Opera, Apple and Mozilla but until the issue is fixed uni­ver­sally fall­back alter­na­tives need to be pro­vided in the form of cap­tions and transcripts.

With video an essen­tial and grow­ing part of today’s web, pro­pri­etary for­mats lock out many users unless appro­pri­ate alter­na­tives or fall­back are pro­vided. While HTML5 and the <video> ele­ment could rec­tify ongo­ing issues with codec sup­port on the desk­top, lack of <video> sup­port across browsers and then the addi­tional work to bring this to mobile mean we are cer­tainly not there yet. This is not to say that striv­ing for a stan­dards based approach that HTML5 will even­tu­ally offer should be ignored in favour of pro­pri­etary formats.

What about the screen readers?

Per­haps the biggest ques­tion that comes to mind with mobile acces­si­bil­ity is sup­port for users of screen read­ers, the poster child for acces­si­bil­ity. Rightly or wrongly screen reader users are con­sid­ered the most extreme users to accom­mo­date when it comes to access­ing con­tent, an issue that is mag­ni­fied when it comes to mobile browsing.

On the desk­top screen read­ers are able to access web con­tent via the browser using hooks pro­vided by acces­si­bil­ity API’s such as MSAA, IAccessible2 and UI Automa­tion. Unfor­tu­nately the walled gar­den nature of mobile plat­forms means that no such shared API’s exist across mobile plat­forms. The AEGIS project (Open Acces­si­bil­ity Every­where) has set out to cre­ate a shared API but there is no sched­uled release for this, or indeed an out­line of what it would entail and how it would be deployed across platforms.

For now mobile screen reader users are restricted to plat­form spe­cific screen read­ers such as Voiceover on iPhone or Talks on Nokia and Black­berry. This is a start at least and the key thing to know is that if you accom­mo­date for screen read­ers on the desk­top you will be build­ing in access to con­tent on mobile what­ever screen reader or plat­form is used now or in the future.

Look­ing ahead

As we’ve seen there are some sig­nif­i­cant chal­lenges to uni­ver­sal access across devices for diverse users. How­ever by build­ing two ver­sions of one site we are in dan­ger of mak­ing the same mis­takes we made on the desk­top in the late 90s.

Back then sep­a­rate text-​​only web­sites were con­sid­ered a one shot acces­si­bil­ity solu­tion that in real­ity failed dis­mally. Many text only web­sites, while tech­ni­cally acces­si­ble to screen read­ers, for­feited acces­si­bil­ity for users with other needs such as peo­ple with cog­ni­tive prob­lems who need colour, lay­out and images in order to com­pre­hend lay­out. Addi­tion­ally, con­tent was not always equiv­a­lent between the two ver­sions. The same issue hap­pens today with mobile only ver­sions of sites, where links or con­tent are often stripped out to make the mobile ver­sion lighter.

Sep­a­rate ver­sions means that acces­si­bil­ity becomes com­part­men­tal­ized: a bolt on rather than built in fea­ture. It also means that peo­ple with­out acces­si­bil­ity needs don’t ben­e­fit from the addi­tional usabil­ity that an acces­si­ble site gives, and mobile users fall neatly into this group. Emerg­ing tech­nolo­gies may still be var­i­ously sup­ported across desk­top and mobile browsers but build­ing to open stan­dards will lead to ‘one web’; an eas­ier place to nav­i­gate what­ever your browser, plat­form or assis­tive tech­nol­ogy and in the long run an eas­ier web to develop for.

While stan­dards sup­port on mobile may seem more vari­able than on the desk­top the pos­i­tive side is that base­line mobile browser capa­bil­i­ties are improv­ing fast. In addi­tion to this peo­ple tend to upgrade mobiles every year or so whereas on the desk­top many web users glob­ally still use older less stan­dards com­pli­ant browsers such as IE6 which came out 8 years ago.

With that in mind key things to think about when build­ing web­sites for diverse and mobile users are:

With the web quite lit­er­ally every­where we have a big­ger oblig­a­tion than ever to ensure peo­ple have access no mat­ter what their plat­form, envi­ron­ment or per­sonal needs. If we split the web now we are in dan­ger of los­ing this shared frame­work and true uni­ver­sal­ity across devices.

Further Reading

2 back to overview

Comments on this article

  1. Written by Dwight Vietzke on the 17th of May

    Great arti­cle. I couldn’t agree more.

    An inter­est­ing bi-​​product of my own devel­op­ment work has been the real­iza­tion that con­tent must be stored in a data­base and served to spe­cific devices and not just served from sim­ple pages. Some sort of server script­ing or pro­gram­ming is nec­es­sary to nego­ti­ate the cur­rent field of browsers and devices try­ing to access a web­site, for many reasons.

    If browsers strictly fol­lowed some sort of web stan­dard, it might be pos­si­ble to cre­ate a page dri­ven web­site which could adapt to dif­fer­ent devices via media nego­ti­a­tion, view-​​port spec­i­fi­ca­tion, etc. Yet this is improb­a­ble given the cur­rent trend for browsers (espe­cially IE) to still do their own thing. So a ‘one web’ dynamic web­site is a worth­while goal, but does require sig­nif­i­cant effort to cre­ate a work­able solution.

    The good news is, the lat­est smart­phones and iPhone are now able to process css, javascript and xhtml (when being xhtml MP com­pli­ant) rea­son­ably well. So there actu­ally may be future for the ‘one web’ website.

Leave a comment

Don't forget to keep track of further comments too!