Below are a handful of observations from user testing on mobile websites and applications I’ve seen recently. All users had some form of disability including people with limited mobility, sight impairments, cognitive impairments dyslexia or hearing loss. Testing was carried out using Android or iOS with blind users accessing using the TalkBack or VoiceOver screen readers respectively. For obvious reasons I can’t share with you any details about the products.
If you have a disability, are a mobile user and have 5 minutes to spare please take a moment to fill out this online survey on mobile accessibility hosted on the The Paciello Group (TPG) site.
The data gathered will be a useful insight into mobile usage and help us inform mobile accessibility strategy and development.
Obviously the more people filling it in the better to please pass this on to any other mailing lists, blogs or lists you might feel appropriate.
Big thank you to TPG and Kevin Chao for kick starting this.
Update February 1st, 2013
The preliminary results are in and available on the TPG website. It looks like more analysis is to come but I’d say there are few surprises.
BECTA, a UK government agency focusing on the use of technology throughout learning, recently invited me to contribute and article on mobile accessibility.
Grab a copy of the article in one of the following formats (sorry, no HTML):
Read this article in Belarussian translated by Patricia Clausnitzer
A question I’m frequently asked by developers is why keyboard access for the Flash is not fully supported across browsers. Opera, Safari, Firefox and Chrome all have problems enabling keyboard users to tab into and out of Flash content while Internet Explorer works fine.
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:
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.
Last week I spent some time with my boyfriend’s Mum, Patricia, who really struggles with scrolling and empty space on web pages. The two things combined conspire against her making it a real effort to get to the link she wants. She’s mostly a Facebook user which is confusing at the best of times but if she zooms in – so she can see better – she becomes utterly lost and then stuck because she can’t get the mouse on the scroll bar.
What’s really heartbreaking is that she thinks it’s either her fault, “I broke it!”, or that she is stupid. She is of course no more stupid than she is able to break the Internet but it still really knocks her confidence when browsing (and yes, I’m shaking my fist at you Facebook).
This is a problem I hear about a lot and is due to horizontal toolbars forced to appear when pages are scaled in a browser. It also poses problems for users with access technologies such as screen magnification and will be familiar if you browse on your mobile.
When a page is magnified to the extent where you can only see what is a credit card amount of the page on your screen it is really easy to get disorientated and lose context. This is explained much better below by Johann De Boer from AbilityNet who is a screen magnification user himself:
I’m using Opera where I can scale the full page up 900% by selecting the icon on the Status bar along the bottom of the browser. By doing this I’m replicating the screen size that some screen magnification users may have.
By scaling 900% a horizontal scroll bar appears at the bottom of the page and white space on the page starts to dominate. When scrolling it becomes tricky figuring out where you are and where in the page you want to be.
There are a couple of different Views that you can access via the View menu on your toolbar: ‘Small screen rendering’ and ‘Fit to width’ which give two slightly different renderings of your page.
Small screen rendering
By selecting ‘Small screen rendering’ from the View menu you immediately get the web page content presented in a single column layout as shown below.
‘Small screen rendering’ is intended to replicate how a page may appear in a mobile browser by doing the following:
- Disables style sheets, colours, spacers and corner images (not larger images)
- Table cells are set to display:inline
- Embed, applet, object and iframe are set to display:none
- Fonts scaled and structure retained
- Maximum of 140 pixels width
It’s a good way to test how pages look in a mobile browser but also an excellent tool for preventing a horizontal toolbar appearing when you scale the page up. Unlike ‘Fit to width’ – described below – it also removes empty space.
Fit to width
‘Fit to width’ resizes page elements such as columns, text areas and images so that they are no wider than the actual width of the screen. A key benefit over small screen rendering is that it doesn’t change the layout of the page but instead simply wraps content when it is scaled so there is no need for a horizontal toolbar. Effectively you’ll notice nothing change about the page either zoomed in or out.
Take your pick
I can’t really recommend one over the other as both have befits depending on the circumstances. Having played around with these features with Patricia she preferred ‘Fit to width’ as the page retains the layout she is familiar with. When the page is scaled she’d rather retain the context of the page and live with the white space while doing away with the horizontal scrolling.
For me however I often use ‘Small screen rendering’ when reading blogs where line lengths seems to stretch endlessly across my screen making it difficult to follow. You can also use ‘Fit to width’ and simply make the browser window smaller too. Browsing on a mobile I also often switch my settings to single column layout (or Mobile view in both Opera Mobile and Opera Mini) so I don’t spend time zooming in and out.
So if you know someone who gets frustrated with zooming, scrolling and getting lost in space try these out and see what you think.
Disclaimer: I suppose it would be unsporting of me to not mention that other browsers offer various solutions given I work at Opera but I happen to like ours best…(she says cheekily).
Most things have a shelf life and technology on the web is no different. Tricks and hacks that once seemed to save the day sometimes need to be retired as newer technologies or techniques get implemented.
I can think of plenty of accessibility solutions that have found their way into the archives such as using an asterisk (*) for a bullet image, text versions of websites and verbose title text around links – to mention just a few.
So what about the skip link? Firstly Gez Lemon describes Skip links as follows:
Skip links are links to another part of the page that allow visitors to navigate their way around a web document, without having to cycle through a huge list of links.
On todays web skip links are a good thing. They’ve played their part in improving the usability of the web for users with disabilities and mobile devices. Screen readers, voice input software, keyboard only users and those browsing on mobile devices all benefit.
Skip links are becoming increasingly mainstream despite them not being an explicit requirement of WCAG 1.0, the defacto standard up until December 2008. Much of what was implied in WCAG 1.0 however has become explicit in 2.0 and the skip link finds itself as a sufficient technique in for Success Criteria 2.4.1: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages securing itself a place in Level A no less.
So why am I suggesting – given the skip link’s new found status – that they may have a shelf life? Well here goes…
Having a well constructed document that marks up headings, paragraphs and lists, and has well written and grouped links already goes a long way to supporting the user orientate and navigate within a page.
Access technologies such as voice input and screen readers hook into these so that users can use keyboard commands to jump from heading to heading, paragraph to paragraph and so on. Having these in place means users are not forced to tab laboriously through numerous page elements but instead ”scan” a page in much the same way a sighted user can.
Of course this is nothing new. There has always been a question mark over the need for skip links when your documents are well constructed but what has changed is that there is a larger critical mass of websites now following web standards than before – ever the optimist – be it through a desire to be accessible, searchable or findable.
HTML5 introduces new elements designed, in part, to replace the
divs in HTML4. These include
header, nav, section, article, aside, and footer. This immediately gives pages a structure by identifying content areas within a page.
The idea is that a screen reader can inform the user of where they are in the page as well as provide a means for the user to jump to sections, much like you can jump between headings with a screen reader. For example I might want to read each blog post on the home page of this blog by jumping from
section then jump to an
aside to browse through the categories or recommended links.
This doesn’t mean that heading levels (h1 to h6) become redundant but rather they are now presented within related container blocks. Using the new elements may well also impact how you structure your headings and put to rest ongoing debates about repeated h1′s in a page and using the website name as the h1.
What will be particularly useful on complex, content heavy sites is that you wont need hacks such as hidden headings for content that is otherwise visually obvious. For example many sites will code a hidden heading at the top of sub navigation, such as “Sub-navigation”, in order to orientate a screen reader user.
Another example of “too much accessibility thank you very much” is when developers get a little over eager with skip links and add in what seems like a whole new set of navigation such as “Skip to main content”, “Skip to sub navigation”, “Skip to search”, “Skip to footer” and so on.
You really don’t need more than “Skip to main content” and possibly “Skip to sub-navigation”. A “Skip to search link” is especially redundant as users can do a search for it by looking for the text “search” or using keyboard shortcuts. Adding these new HTML5 elements should remove the temptation to overdo skip links which can add to the complexity of site navigation as well as reduce the number of headings used in a page.
You can start using these new HTML5 elements now in your markup as most browsers are able to handle them however what level of support is being built into screen readers for new elements and attributes in HTML5 is hazy. The vendors are not participating in the HTML5 Working group despite repeated invitations from the web developer community. That said, while the specification wont be finished until 2022 you can start using HTML5 now.
WAI-ARIA landmark roles
Just as HTML5 introduces section elements so WAI-ARIA introduces landmark roles. Landmark roles allow screen reader users to orientate themselves in a page by informing them if they are in the
article, banner, complementary, contentinfo, navigation, main or
search. You can read more about this in Gez Lemon’s excellent article Introducing WAI-ARIA.
Landmark roles are intended to allow screen reader users to orientate and navigate around the page thereby doing away with the need for skip links. Questions have been asked about how adding both landmark roles and HTML5 section elements may work together with Steve Faulkner recommending that landmark roles be used now and removed once support for HTML5 becomes more robust.
The new sectioning elements in HTML5 have some overlap with ARIA landmark roles, but in a majority of of cases there is no equivalent for the ARIA landmark roles in HTML5. It is suggested that where there is a similarity the ARIA roles can be used to provide semantic identification that has a practical use now, for example if you want to use the HTML5
role="navigation"to it, so supporting Assistive Technology (AT) can convey the semantic information to users. When HTML5 elements such as nav are supported by AT, you can then remove the role as it will no longer be required.
Current support for WAI-ARIA is shaping up with all browsers working on it as well as the main screen reader vendors. The specification is also likely to be completed 2009 and is becoming more and more mainstream.
Browsers are getting better and better at helping users access content. The Web Accessibility Initiative publishes guidance not just for content in the form of Web Content Accessibility Guidelines (WCAG) but also user agent developers in the from of the User Agent Accessibility Guidelines (UAAG). The relationship between UAAG and WCAG means that browser should offer options to help users navigate around the page via the browser and not just the content.
Opera – where I work – provide spatial navigation and single key shortcuts. Spatial navigation allows you to use your Shift + arrow keys to go up, down, left or right within a page which gives much more flexibility than tabbing in a page in a linear fashion which is the main barrier that skip links address. Single key shortcuts allow you to jump between headings, links, page elements as well as customise your shortcuts. Again allowing the user quick access to content areas within a page.
Opera Mobile and Mini also offer spatial navigation to make browsing easier. This is a huge improvement on the WAP style pages where you’re forced to navigate through the page linearly. In addition to this every numeric key (0-9) has a pre-programmed function that you can customise. Within this context skip links seem less necessary however they do still have a huge benefit on WAP style pages.
Knowing enhancements such as spatial navigation and single key shortcuts are available in desktop and mobile browsers decreases the need for skip links however this does assume that all users know how to use their browser and many do not. While that is not your problem as a developer it equally can’t be ignored and I don’t think can be considered a full alternative just yet.
That aside it would be interesting to review the browsers and versions that you support and see what the baseline of navigational aids there are in the browsers and assess whether skip links are indeed necessary.
So is that it for skip links?
No, not yet. If you have skip links there’s no reason to remove them. Adding enhancements are never a bad thing and skip links are unobtrusive when implemented properly. It is however worth reviewing your content to ensure you have a logical document structure that can be read by access technology: good headings, lists, well worded links and so on. My personal take is that on a simple site such as this blog this is sufficient, on a more complex site you still may want to implement skip links. Opinion however, will always be divided so you need to think what suits your site best.
Adding in WAI-ARIA landmark roles and HTML5 can do no harm at this point but can’t be relied on in full. Apart from anything else – browser and access technology support – there is a learning curve with any new technology on the web that the user has to go through. We can’t assume that screen reader users will immediately be familiar with the benefits that HTML5 and WAI-ARIA bring, as with navigating Flash when it became more accessible users had to become comfortable with it.
So has the skip link passed it’s best before date? No. Does it have a shelf life? Yes, I think it does. Keep your document structure logical and gradually implement WAI-ARIA and HTML5 and you may just find skip links become redundant.