Dylan Barrell Talks Amaze
Here is our very own VP of Product Development, Dylan Barrell, to tell us a little bit more about Amaze.
First, give us a one-sentence summary of what Amaze is.
It’s a way to fix applications that aren’t accessible without changing the source code of those applications. It’s amazing!
How does it work?
It works a little bit like a stylesheet for accessibility. It looks for patterns inside the application; and then in real-time replaces pieces of the code with HTML code that is accessible or that makes the application accessible to a variety of different assistive technologies. For example, you have an image that has a title attribute instead of alt text, which is a common mistake; this is one of the patterns Amaze recognizes is misplaced alternative text, and it will go and grab that alternative text and put it in the right place. But those changes only remain as long as the user is on the site; the application itself is still broken. Amaze leverages HTML’s capability to make changes to the document dynamically to add accessibility to the information.
When did you start working on what we now know as Amaze?
I don’t remember exactly… I think it was sometime in 2010 – a while back. I remember that it was around the time we created FireEyes, and I was creating the left-hand navigation for the FireEyes server. We’d got some HTML sent back from the designers which had the stylesheets and the mock-up and everything, but obviously the accessibility information was not there. So there was no information in the HTML about which tab was selected and how many tabs there were and all that, but there was style information there that told the browser which tab to highlight. I was looking at that code and I thought, “You know what? I could just look for that style, and I could apply the accessibility information dynamically. I don’t actually need to go and change the source code to do this at all.” So that’s where the germination of the idea occurred.
Obviously, we’ve progressed a lot further from the initial thought to where we are today, and we’ve encountered a lot of difficulties along the way – limitations and things we had to solve in order to be able to do this. In particular, what I talked about is pretty good for static webpages, but what about dynamic ones that are changing as you experience the site – how do you recognize those changes dynamically and recognize which you have to react to?
What are the differences between the free plug-in and the “include” version of Amaze?
The plug-in is for 3rd party applications like Facebook and Twitter where we don’t have the ability to add anything into the page at all. If we don’t have any access to the application such that we cannot insert any JavaScript in the page whatsoever, then we need to find a way of executing Javascript on the page; and the only way to do that is with a browser plug-in. It can insert the core functionality of Amaze and then fetch and execute all the overlays for that site; the static ones and the dynamic ones.
If a company wants to fix their own applications or their own website where they have the ability to insert the JavaScript tag, similar to what you would do with Google Analytics, then you would prefer to use the include version of Amaze. It doesn’t require the end user to install anything, so if the end user can’t install a plug-in for whatever reason – they’re one a work machine, etc. – they can still benefit from the Amaze overlays. The include mechanism is much more robust in that it can work across multiple browsers without the user having to install anything. They’re essentially the same code, they’re just execute in the document in different ways.
What are the limitations of Amaze?
It can only work on HTML. PDF documents, Flash documents, and Silverlight are not supported because they don’t share that attribute that allows for Javascript to dynamically alter the code. Also there are a few differences between different browsers as to the way events fire inside them. So older browsers, like Internet Explorer 7 and 8 have a different event model from newer browsers. Although it’s not necessarily a limitation, we definitely had to jump through some hoops to get it to work well for dynamic overlays in all the different browsers. It’s not something we’ve encountered yet, but it is something we know is a limitation. Amaze is best for IE 9, Firefox, Safari, and Chrome.
Can customers create their own accessible overlays?
We have a development API that helps people create their own overlays and we can give that to customers.
What are the advantages of Amaze?
I think one of the major advantages of Amaze is that it allows companies to fix existing applications without impacting their development resources. They can get in a 3rd party like ourselves to come in, and without having access to their source code and getting involved in their development process, we can apply our expertise in accessibility to their application totally independently of their current development priorities. So if they have different priorities – if they want to get certain features up or make certain improvements to their websites, but at the same time they want to make it accessible – this allows them to bring us in as a 3rd party without impacting any of their existing development processes. That’s a very attractive thing from the point of view of a CIO, particularly for companies who are doing this because they are under threat of litigation. All of the sudden they have, as far as they’re concerned, this new requirement and an additional burden on their resources, and for them to be able to turn this task over to us without impacting their other business priorities is a huge advantage.
This disadvantage of this format is that you’re not fixing your core application, and it’s easy for Amaze to be seen as a band-aid. But the silver lining is that every overlay we write is a blueprint for how to fix that core application.
How would you respond to concerns that technology like the Amaze plug-in essentially lets websites like Facebook and Twitter off the hook for becoming accessible?
There’s the legal side of it, and then there’s the practical side. For me, as a Facebook developer to know that some small little company like Deque had gone and made my site accessible even though they don’t have access to our source code, I’d be kind of embarrassed. They’re supposed to be the best in the the industry.
From a legal point of view, I can’t really comment. I think, from a practical perspective, it makes a difference to people today that they can use Facebook and Twitter, regardless of the difficulties that they are having making it accessible. I think that’s the most important thing is to see the difference in the lives of people with disabilities, particularly young people with disabilities who are really cut off from the rest of their peers because they don’t have equal access to a very important communication and interaction tools for today’s youth. That for me, outweighs everything else. I don’t think a multi-billion dollar company like Facebook could turn around and say “Deque has made our site accessible. We don’t have to,” – I don’t think that’s going to unburden them from a legal perspective. I don’t think sites like Facebook and Twitter can relinquish some kind of responsibility for the impact they have on people’s lives.
If you are going to CSUN, make sure you stop by Deque’s space for a live demo!
