There has been ongoing discussion, mainly on twitter, about Dragon naturally speaking, ARIA and Accessibility APIs. A recent tweet informs these notes.
#dragon doesn’t support #aria & according to @ewaccess, it probably never will. It’s definitely an AT solution nonetheless. #a11yCampTO
— Denis Boudreau (@dboudreau) November 16, 2013
Accessibility is a social contract
Accessibility advocates ask developers and browser vendors to do their part to make HTML content accessible. A technological framework for this is provided via web standards including: HTML, WAI-ARIA and WCAG. If Assistive Technology vendors do not work with developers and browser vendors by making use of the information provided through standardized interfaces for making HTML content accessible, it’s the user that gets screwed, but not by the developer or the browser vendor as they are fulfilling their part of the social contract.
A Misunderstanding of ARIA
ARIA is a tool that allows developers to represent the role, states and properties of HTML content in accessibility APIs. It is the job of browser to support the connections between an ARIA attribute and it’s representation in an accessibility API (and browsers implementers have stepped up). It is the job of the developer to add the ARIA attributes (and scripted behaviour) to HTML when they build custom controls. It is the job of an assistive technology to make use of these standard platform accessibility APIs to convey information about content to users. The three parties involved: developer, browser and assistive tech all have a responsibility. If developers and browsers fulfill their responsibilities by coding and exposing the information according to web standards, it is incumbent on the assistive technology to make use of this information, otherwise their users suffer.
(added 21/11/2013)
Requirements on applications as per the Section 508 refresh (503.3 is relevant to Dragon):
503.3 Alternative User Interfaces. Where an application provides an alternative user interface that functions as assistive technology, the application shall use platform and other industry standard accessibility services to provide the alternate user interface. [emphasis mine]
Further reading:
Notes on Guidelines For Speech accessible HTML for Dragon NaturallySpeaking
Comments
Thanks, Steve. I appreciate your time and attention to this discussion. I’ve previously asked asked how accessibility advocates should pitch to Nuance that Dragon NaturallySpeaking should adopt of the technological frameworks adopted above, and what you propose above is humble and persuasive. As I stated in my (sensationally-titled) Accessibility Camp Toronto presentation “Dragon Sucks!:” in spite of Dragon’s inability to directly access most modern-web content, nothing on the web is inaccessible to me. Any stories that focus on suffering users could be rightly dismissed for three reasons:
1) Dragon has the ability to indirectly access most web content.
2) Affected end users have cheap and powerful AT (like ergonomic pointing devices) at their disposal to fill in access gaps.
3) Nuance looks the other way toward developers of third party tools that improve Dragon’s web access capability, like KnowBrainer, SpeechStart+, and VoiceTeach (despite these vendors and developers probably being in violation of Dragon’s EULA).
An effective pitch, then, focuses not on the impacted end-users, but on the developers who can champion their tool as long as Nuance fulfills their end of the social contract.
Thanks again,
Eric (@ewaccess)
Hi Eric, it sounds to me like you are saying that web developers don’t have to do anything special (over and above following the standards) to support dragon users, is that correct?
I partially agree with both of you.
Nuance could and indeed pay greater attention to standards.
We need to concentrate on the positives for nuance in terms of how interoperability with standards would improve the user experience for all.
I was a Nuance reseller for years and despite the high numbers of people with disabilities amongst the customer base AT is not seen as a key market.
Browsing the web using Dragon alone is not a satisfactory experience I hate using mouse grid. Thankfully I have use of an ergonomic mouse this is a common use case as Eric has pointed out.
We need to have a demonstrable argument on how adoption of standards will benefit Nuance in its pursuit of the broadest consumer market. I fear that only then will they show interest.
Thanks Steve, and Denis et al who contributed to the discussion on Twitter. What I don’t understand is why Nuance doesn’t follow the basic guidelines/specs for some elements and attributes.
nor do I.
OMG, OMG, OMG, I’ve just been immortalized. 🙂
Seriously, it feels to me we are all in agreement here. I totally believe in this social contract you’re describing Steve, and I feel it can only work when all parties fulfill their part. The issue we face is that according to the information we have, Nuance is not positioning Dragon as an assistive technology, therefore sees very little value in implementing aria or supporting accessibility APIs. They probably think their resources are better invested in catering to their larger user base who want constant improvements in the more visible features. One only needs to look at the lack of accessibility support to determine that at some level their lack of commitment to accessibility can only be true: real support for accessibility is, after all, pretty much non existent.
As it turns out, according to a good friend of mine, there are more users of Dragon than there are users of screen readers out there. I am still waiting to see documented sources for that, but I see no reason to doubt her word. That has to be a game changing perspective for anyone who is focused on providing the most accessible user experience possible.
Keeping that in mind, as long as we’re willing to acknowledge the fact that a lot of people with mobility impairments are relying on Dragon as the main way to navigate, interact and communicate using the web, then it becomes clear that in the best interest of inclusion, this is a real problem. We have to convince Nuance of how important their role needs to become in bridging the gap between their technology and the solutions that developers are implementing to fix accessibility problems. In other words, we need to help them understand the business case for accessibility API support and incidentally, how their current position, in the long run, can be detrimental both to digital inclusion and their reputation as a corporate citizen. When it comes to Dragon, all the pieces are there… We just lack the commitment from the vendor.
Nobody can deny the fact that ARIA, along with informed, responsible coding best practices is the way of the future when it comes to accessibility: this is what everyone is aligning too and pretending otherwise Is pretty much the equivalent if burying one’s head in the sand… That is, as long as the solutions are adequately supported by the vendors providing the tools people with disabilities use. When a major player refuses to play along, everyone is set back.
By showing a lack of interest in supporting accessibility APIs and ARI, Nuance is forcing many of us to resist using the gem that can otherwise be ARIA as the main way of providing accessible solutions on the web. Nuance strategy probably isn’t to position itself as the new IE6 of a11y support, but who knows… Maybe this is the reputation the future has in store for them if they don’t change their game plan.
As ARIA gains traction with developers and designers alike, and as more of them turn to ARIA to provide an accessible experience to their users, remaining insensitive to the impact the lack of accessibility support in Dragon has on people with mobility impairments can only become increasingly indefensible. Whether Nuance likes it or not, Dragon IS used as an AT by many – this is something the vendor has any control over, nor should they.
Point is, it is in everyone’s best interest (including Nuance) that we help them understand this. I know I’m an helpless idealistic when it cones to these things, but I encourage us to adopt a constructive approach as we discuss this issue, so we can open a respectful dialog with Nuance and help them understand that in 2013, accessibility is not just a nice to have anymore, it needs to be a core value because it’s bound to meet the needs of an increasingly high number of their users who will need it more and more as they age. Just thought I’d put it out there…
Whether the vendor sees it’s product as AT or not today is irrelevant. It is used as AT and therefore, it is assistive technology at some level. They just haven’t realized it yet. And when they do, we can only hope they get on with the program.
Until then, some of us will remain uncomfortable with going full swing with ARIA. Because regardless of the potential it has that far more exceeds the limitations caused by some of those other less widely recognized assistive technologies, sorry to say, but ARIA remains, to this day, a very screen reader centric solution to web accessibility. And we have a responsibility to move beyond the screen reader.
I agree that it doesn’t really matter if Nuance thinks Dragon is AT or not.
But it actually doesn’t matter if they do or not. The fact is that taking advantage of the accessibility APIs and the features of HTML and ARIA and content providers’ adherence to WCAG will make their product work better. For all of their customers. A better product generally results in more revenue. Most companies tend to like more revenue, and I imagine Nuance would not be an exception.
As a bonus, improving the lives of people who use it as AT would make them look good while making more money.
Hi Denis, thanks for an essay of comment 🙂
I think it is a dangerous precedent to start comparing user population sizes.
Agreed, and that’s what I have been trying to raise awareness of.
You continue to create a false division, one which this post was aimed at dispelling. Except for a small subset, ARIA support = accessibility API support. For example: A native HTML
For example, the following 3:
Are all exposed like this in MSAA in Firefox:
AT do not need to know ARIA, they only need to know a standard accessibility API that has been around for many years.
Furthermore and because of this fact browsers themselves in some cases use ARIA to convey the semantics of native controls; Chrome uses
role="spinbutton"andaria-valuemin/aria-valuemaxetc on their implementation of the HTML5 input type=”date”.While understandable, it is not practical as, for better or worse, the modern web is built on custom HTML and will only become more so with the rise of web components. ARIA is only screen reader centric as screen readers are currently the class of AT that have stepped up to the challenge of supporting standards (albeit some, reluctantly) and providing their users access to the modern web. Accessibility API support is the cornerstone of AT user agents accessibility support, whatever form that takes.
It should also be noted that while browsers are mainstream technologies, the majority are committed to supporting accessibility in the general sense and in the specific sense of conveying semantics via accessibility APIs.
Hi Sarah, agreed.
As I noted in my response to Denis, browsers are not AT, yet they generally go out of their way to support users with disabilities. Part of the issue with Nuance may be that it has a monopoly position in the market and that is never good for users.
Is anyone or any company thinking of making a Dragon-like AT? Something meant to be AT, something cross-platform. Something that would use ARIA?
I mean, instead of relying on a single company whose goals are elsewhere… imagine if everyone were completely reliant on Freedom Scientific because there was only one screen reader in the world, and it only ran on Windows and cost thousands, and what if their corporate goal wasn’t their product as AT but something meant for people driving cars while using a built-in menu?
In other words, where is the equivalent of NVDA for speech recognition software?
I agree. Screen reader accessibility would be nowhere near where it is today had not it been for NVDA. Monopoly is never a good thing and JAWS needed to be taken off of their pedestal. Maybe the same s true for Dragon? Nothing like a little competition to level the playing field.
I’m sorry, brevity has never been my strong suit. I’ll try to make this one shorter. 🙂
I agree that this is a dangerous precedent and am not doing it lightly. We are busting our chops every single day in order to create the best experience possible for non-sighted screen reader users, yet very few are doing anything significant for accessibility outside of that user group. We could talk about low vision users and testing with zoomText or simply text resize vs. browser zoom, users with auditory impairments with the complexity of the language used or, in this case, users with mobility impairments with Dragon (testing with more than just the inevitable tabulation key). And I’m not even getting into cognitive disabilities, which is an even larger user group when you pull all these people together.
I guess what I’m trying to say is we should take real actions to be less screen reader centric and accounting for testing with Dragon for keyboard navigation could be a first step, considering how many users there are. And when developers only rely on ARIA to fix accessibility issues and Dragon users can’t benefit from that because Nuance doesn’t bother implementing, then what options are these users left with, really?
As for the confusion between APIs and implicit ARIA support, I blame my lack of knowledge and understanding. Thank you for explaining. For some reason, I was seeing a difference but you’re right, why should there be one? It’s all about purpose and semantic being conveyed through the user agent, doesn’t really matter if it comes from ARIA or HTML.
I see your point: if Dragon wasn’t “broken” when it comes to accessibility API support, then the information conveyed through ARIA would still end up being conveyed back to the software. Everyone would win. It’s “just” that some of the current players don’t play well with others.
Finally, the whole debate about ARIA being screen reader centric is really nothing but a chicken and egg debate. Should we refrain from using ARIA because only screen readers have stepped up to the challenge or should we refrain from using it because only screen readers have stepped up to the challenge? I guess it all depends if you care about the users first, or advancing technology. I’m not implying you would be of the latter at all, I know you’re not, and both options certainly aren’t mutually exclusive either. But while I acknowledge that today’s web is built on custom HTML, making sure we are inclusive of all users with diversities in web use also has to play a role in the choice we make.
It’s when we tend to benefit one to the detriment of the other that I become uncomfortable. And honestly, so should we all.
I’m a little short on time but wanted to continue the discussion so some short points below:
1 Creating an accurate speech recognition engine is much more complex and costly than creating a screen reader. That’s why only large companies and academic institutions have ever been in the game. Most of the smaller companies were bought up by Microsoft google or nuance. I just don’t think it is likely to happen any time soon in the same way that NVDA challenged JAWS.
2 I agree API support should be the goal not ARIA.
3 Dragon has the ability for simple user generated macro creation which in a desktop environment are very valuable and get around issues much like JAWS scripts but in a much cheaper and consumer friendly way. This way of working breaks when it comes to the web.
4 One of dragon’s worst user experiences is web browsing so if we demonstrate use cases for non disabled consumers benefiting from accessibility API compatibility we might have a chance as hands free operation becomes more and more important if you are driving or walking etc etc. these are areas that Nuance knows and understands better than the accessibility market so we have to frame our approach differently.
I know people at Nuance would like to have better business cases to take to their bosses so maybe if we can demonstrate this we might get somewhere. I’m willing to engage with them on this.
Neil,
I’ll be glad to join you in this engagement. I’m not (nor have I ever been) a Dragon vendor, but I’ve observed that users with disabilities like me tend to be the biggest customers in the VAR channel. I think if we can go back to the VARs and explain to them “OK, here’s more value-add for your customers” they too can approach Nuance here.