The latest Opera browser has been released; Opera 12. In many ways Opera is a great browser and Opera 12 includes lots of shiny new stuff, but still no support for assistive technology (AT) users. Opera excels in implementing HTML5 support for some users, but others are left behind. Here are some suggestions on how this could change:
First steps
First thing is Opera needs to decide if you want to commit to making your products accessible to assistive technology (AT) users and if so what products and on what platforms.
Dedicated Resources and Strategy
If you decide you want to support AT users then you need to dedicate resources to it, it is suggested that it will be a waste of time unless you commit to having a permanent team who’s responsibility it is to implement, maintain and liaise with other opera engineers etc on accessibility. In other words you need an accessibility strategy.
If you decided to implement accessibility support, for example on the Windows platform, it is suggested you would need to implement:
- Microsoft Active Accessibility (MSAA)
- IAccessible2 (IA2)
- Expose MS COM interfaces ISimpleDOM to provide access to the DOM tree.
Implement the Role, State, Events and Property mappings as per:
- WAI-ARIA 1.0 User Agent Implementation Guide
- HTML to Platform Accessibility APIs Implementation Guide
Probably the easiest thing to do on this score is look at Mozilla’s implementation (all the source code is there) and talk to the Mozilla accessibility engineers.
Comments
Great comments.
Opera actually did start an accessibility project ages ago (see Opera Screen Reader Support), but unfortunately it has gone quiet since then. I wonder what has happened with that accessibility project?
Seems to me that Opera has given up on Accessibility — a shame. Two years or so ago, they had some of the best ally folks in the industry. Most have left or were let go. I’ve never understood this given that Opera’s founder was a stalwart supporter of accessibility during the early days of the W3C….
Hi Mike,
Opera does not have a public accessibility strategy, unlike Mozilla, Microsoft, Google and Apple, which does suggest that they have no commitment in this area.
Hi Mike,
Unfortunately they just lost another one: Opera’s Chief Standards Officer Leaves The Company.
Hi Stefan, thanks for the link. It is interesting to note that at some point Opera made an attempt, but unfortunately they never followed up, it requires a solid and continuing commitment to product accessibility to make it happen.
Only business or legal motivators will move Opera to fix accessibility and to date neither have been strong enough to make it a priority however this could change.
The 21st Century Video and Communications Act in the USA says that by 2013 all mobile handsets must ship with an accessible browser. Given Opera is one of the most widely used mobile browsers globally, plus it’s desire to gain greater market share in the USA, I can’t see how they can ignore the Act without engineering themselves out of the mobile market altogether. If they make Opera Mobile accessible then I’d hope they follow through and make the Windows browser accessible. I lobbied hard for this to happen when I was working there. Fixing the desktop was one thing but adding in support on mobile would give users an amazing experience whereby they could use their browser of choice across devices. When the browser got accepted into the Apple Store it was such a wasted opportunity that it didn’t support Voiceover.
I know some people are sceptical about how quickly or influential the 21st Century Act will be but we have been here before. The US Government mandating Federal websites to produce accessible content was in part a motivator for Adobe to fix PDF and Macromedia to make Flash accessible. I really do hope the Act kickstarts genuine efforts to support all users on mobile and desktop. While I fear Opera may have missed the boat on desktop I think that if they do this in conjunction with mobile they may be able to win back some hearts and minds and, of course, users.
Some details about the Act can be found at: https://www.iheni.com/mobile-accessibility-presentation-at-csun-2012/#comment-143073
Finally, Chaals leaving is a significant loss to Opera, and a big gain to whatever he goes on to. He’s worked hard to fight the corner of accessibility within Opera and I wish him all the luck in the world.
Hi Stefan and Steve,
Opera did have some support for Voiceover in Opera 10 (https://www.iheni.com/using-opera-10-beta-with-voiceover/) but I’m not sure how well this has held up. I’d heard it had regressed a little but I’ve not tested it myself.
Indeed, Henny, it has regressed. (Unless it was improved in version 12.)
One of the reasons of the lack of progress in screenreader support back in 2007, as I understood, was that Opera needed further technical assistance from screenreader vendors. Indeed, one can still see that the basics for an accessibility API are there but that it simply doesn’t get to work as you’d expect (on NVDA: not voicing menu items and many other elements, etc.)
Nonetheless when I use accessibility tools to query Opera’s accessibility trees, I don’t see very weird things happening. In fact, I can simply see the application’s window structure and interactive controls, their roles and names just as happens with e.g. Firefox.
So an interesting question would be: what is Opera doing wrong* in not making basic screenreader operation on Windows possible. Or could an improvement also come from the screenreaders’ side in better processing the accessibility states that Opera does communicate?
* Note: I’m only talking on the very basics of interacting with menu structures, dialogs and options screens. I’m well aware that a long road lies ahead of that foundation to make the entire application accessible and usable with all of its features, as well as all sorts of web content you will find today.
Thank you for the link to this accessibility law in the US, Henny! I didn’t know of its existence yet but I agree that for Opera’s continuing presence in the mobile world this is not a development that can be ignored.
In fact, I’m already somewhat concerned about a bias in Opera towards accessibility improvements only on mobile. As a mainly-keyboard user on desktop I see many possible improvements for mobile website navigation that are overlooked.
Perhaps an additional incentive would be selective browser admission on desktop based on accessibility requirements. Opera fought hard for equal admission in the desktop browser world, it is only fair that they cater for equal admission of their users in turn.
Hi Fabian,
Indeed it requires a collaboritive effort between browser and AT vendors. Who knows what goes on behind the scenes as this information is not public, but as I have stated, Opera has not made any public commitment to support assistive technology users.
To clarify Opera’s current accessibility support, I have uploaded 2 videos. The first Inspecting accessibility information exposed in the Opera 12 UI illustrates that the Opera user interface does expose accessibility information, but critical “accessible name” information is not exposed. The second Inspecting accessibility information exposed in a web page viewed in Opera 12 illustrates that no accessiblity information is exposed for HTML content.
Thanks Steve! On retesting with the tool you mentioned I can now verify that Opera 9.5 did, and more recent versions do not, expose the specific accessible names of UI elements on Windows. Web page content was never exposed correctly.
I’m not sure how complicated the MSAA, IA2 and related standards are to implement but it looks like it’s up to Opera not screenreader vendors to take the next steps for compatibility.
Hi Fabian,
I think so.
I test most releases of Opera as they are released and have in the past included Opera in my ARIA support tests. Things definitley seem to have gone backwards in Opera 🙁
Fabian, picking up on your point about input from AT vendors being a necessary part of getting accessibility into the browser I couldn’t agree with you more. This goes hand in hand with Opera needing to have a strategy as Steve points out. The problem however is the AT vendors need to want to work with you and to do that they need to see the value in supporting you.
It’s well documented that Freedom Scientific (Jaws) are quite hard to secure support from however Mozilla have support for Jaws in Firefox. They’re open source so there’s a lot to learn from that but more importantly the team over there are super helpful and prepared to share their knowledge. I spoke to them back in 2008 at CSUN and one said “We may be competitors but we don’t compete over accessibility”. Quite right.
The open source screen reader NVDA is definitely worth pursuing. Perhaps Opera would be wise to work closely with them to help them implement HTML5 support in the screen reader in return for NVDA hooking up Opera. A move that would benefit Opera, NVDA and users alike.
The fact that Opera had reasonable support for Voiceover on Mac is something they should look to fix and pursue across devices. IOS is by no means the only fruit but it’s a good place to start.
+1 Re: Opera + NVDA relationship.
It seems Opera have yet more catching up to do in the mobile space as Firefox is now accessible on Android, and Chrome is now accessible on iOS and Android: Accessible Firefox and Chrome on Android and iOS
Another nail in Opera’s coffin I would say, as far as accessibility goes…