Web Accessibility isn’t always easy. Some people are tackling tough problems. Here we talk with Shawn Lauriat who works on Google Docs Accessibility about some of the challenges he faces with screen readers, other assistive technology and changing the world.
Here’s our latest in our series of AccessU 2013 Speaker Interviews:
Google Docs accessibility with Shawn Lauriat
Feel free to download the podcast:
- Interview with Shawn Lauriat, m4a format
- Interview with Shawn Lauriat, mp3 format
- Interview with Shawn Lauriat, .ogg format
Shawn Lauriat transcript
This is the transcript of an interview recorded on April 19th, 2013 between Derek Featherstone, and Shawn Lauriat, who works on the Accessibility of Google Docs. It was recorded over Skype and posted as part of John Slatin AccessU 2013 podcast series.
Derek: You’ve probably heard this before: “Accessibility is easy.” And there are parts of accessibility that are easy. But at the same time, some people are tackling really tough problems, like Shawn Lauriat who works on Google Docs Accessibility. We talk with Shawn about screen reader versions, support for other types of assistive technology and great food and music to try while you’re in Austin. We’re running an entire series of podcast interviews with a number of great speakers for the John Slatin AccessU conference. Coming up May 14th to 16th in Austin, Texas, presented by Knowbility, this is THE conference to go to for in-depth, hands-on, minds-on accessibility training. Check it all out at Knowbility.org. That’s k n o w b i l i t y dot org.
Derek: This is Derek Featherstone with Simply Accessible and I have Shawn Lauriat on the line with me. Shawn is one of the speakers at the upcoming AccessU in May happening in Austin, Texas, being put on by Nobility.
Shawn, how are you doing today?
Shawn: I’m doing well. How are you?
Derek: I’m doing very well, thanks. It’s a pleasure to have you on here talking with us. I know we have a lot of things to talk about. I always like talking with people that are working on really tough problems. I think, from what I can tell, your background and the things that you’re working on right now are pretty tough problems.
Your session is all about making accessibility work for complex web applications. Maybe you could tell us a little bit about yourself and the work that you’re doing, and how that kind of relates to your session. Why should we listen to you in terms of your topic, why are you a good person to listen to for making complex web apps accessible?
Shawn: Sure. I’ll do my best to answer that question. Basically I’ve been working in the web world itself for awhile, since about 2000. I started working with accessibility specifically about 2002, so I have a little over a decade with accessibility experience.
However, since I’ve moved to Google Docs I’ve seen some challenges that are quite new for me. It involves some very complex pieces of coding, pieces of interfaces themselves, and really bending the web to do things that it wasn’t really designed to do in the first place.
Making all of that work with assistive technologies, making all of this work usability wise for people using different input devices, people with different levels or eyesight, people with different levels of cognition, these are all things that are super challenging in Google Docs, but hopefully I’m making things better there.
Derek: That’s cool. It definitely is a complex area to be in. Maybe what you could do is share a little bit more about some of the real difficult challenges. You talked about a few different things there. You’re talking about doing things with the web that it wasn’t really designed to do. Can you tell us a bit more about that, what do you mean by that?
Shawn: Sure. I’ll go into a little more detail during my talk with some concrete examples on everything.
Specifically with the documents editor, which is where I started at Google as just a regular engineer on the documents editor, there are certain concepts in there that are not really cohesive to how web standards work. The concept of pagination with margins, headers, footnotes, page numbers, and such, just the rendering that is expected to work and look the same as it does when you print the document as it does when you’re looking on the screen, whether you’re looking at it in Firefox, Internet Explorer, Chrome, or Safari, it really presented some challenges.
We’re basically using the dom, using HTML and CSS in order to render the page visually on the screen. However, the actual dom itself, which is a little frightening to look at and a little intimidating at first, but once I realized and was gently introduced to the concept of this is purely for visual rendering, this may as well be rendered in SVG, it could be rendered in Canvas, it could be rendered in Flash (but we’re not going to do that one,) it could be rendered in anything.
It’s not actually there for the typical dom structure, which is defining the actual structure of the page. So you have paragraphs and you have spans for specific spans of text that you want to actually effect. You don’t have that with Google Docs rendering, because it’s there specifically just to work the dom into something that will look like something that you would expect a word processor to render.
Having that work with things like screen readers, which typically with web applications are looking for cues from the dom as to where they are, that presents some challenges. We’ve put in place a solution, which I’ll talk about in more detail during my talk, but that works decently in the current iteration. I’m hoping to improve that in my current work. It works decently, but only because of how we’ve introduced another layer of logic in there so that we’re basically doing another level of rendering but instead of it being visual it’s an audible representation.
That’s not the best description, but that’s the fastest description.
Derek: So you have two separate structures. One that is exclusively for the visual side of things, then you have another that’s representing things for assistive technology users.
Shawn: They’re both coming from the same place, but the dom structure itself is used specifically just for the visual representation. We’re doing something completely different for screen reader support. Basically just using ARIA Live regions for reasons that they were not invented, which is as a text-to-speech engine.
Derek: That’s interesting. It does sound kind of complicated. And that’s okay, we’re all trying to do things with the web these days that are going beyond anything that anybody ever imagined when they started putting documents up on the web in the first place. Originally it was all about reading documents and not necessarily about creating documents with rich tools like Google Docs.
One of the things that just popped into my mind as we were talking about it; you mentioned specifically screen readers. One of the things that I’ve seen and heard in the past in terms of Google Docs accessibility in general is that it’s not accessible. It’s been pretty obvious to me that the teams at Google are working to continue to improve accessibility because it’s kind of an important feature, particularly for organizations that are mandated to be accessible and they need to have accessible technology. If you want to take on some of the people and corporations that are already in lots of organizations in terms of office productivity software, then you need to be accessible.
I guess what I’m wondering is can you give us a bit more insight into strategies in terms of what is considered accessible from a Google Docs perspective, whether we’re talking about documents, or spreadsheets, or presentations, or any of the different components? Particularly with respect to different types of screen reader support, I’m wondering are you looking at specific screen readers, do you try to make it so that it works with all screen readers? Would somebody on a Mac using VoiceOver be able to be successful with Google Docs?
Shawn: I’ll answer that in a few different pieces, because there’s a few different questions in there. The first question that I pulled out of that was, “What is considered accessible for Google Docs?”
From my perspective, basically things are accessible when everybody can use the application. It doesn’t matter if you use a screen reader, it doesn’t matter if you have some kind of motor impairment, if you can’t use a mouse or can’t use a keyboard, or whatever it is even if you just have a really old lousy monitor and the contrast is horrible. You need to be able to use the application no matter what the circumstances are. That’s my own measurement of accessibility.
With screen readers specifically, we do support four different screen readers. We try to make it so that it should work with any modern screen reader that supports ARIA and supports general modern web standards. Same with the browser support; anything that is modern we’re going to support. The ones that we have actively tested and support officially to world as, “hey, yes, we support these,” are JAWS, of course because it’s used all over the place, but the most recent version because going back there is some very broken support with ARIA. NVDA actually works quite well and VoiceOver works quite well. Of course, Chrome Vox, which is just a web based screen reader, works very well.
So we are actively trying to make it anything using modern standards will work. The biggest challenge that we’ve had is just in getting it so that it’s easy to get up and running with Docs. That’s one of the big challenges that I’m facing right now. While you can make things work and you can access it with VoiceOver in Safari or you can access it with NVDA in Firefox, if you don’t know how to set it up it just looks completely inaccessible. That’s something that I’m hoping to fix.
We just released a new Quick Start guide at CSUN at the end of February. Hopefully that helps, but I’m also working to make the application itself a little easier to get up and running.
Derek: Cool. Without going into too much detail, it sounds like when you say set up and get things up and running with Google Docs, is it configuration options and things like that or is it something else?
Shawn: There are a couple of pieces. You have to specifically enable screen reader support right now. There’s a major performance hit that happens when you enable it, but if you’re using a screen reader it goes from zero support to it works. User perception wise, it works quickly enough. But it is enough of a performance hit that it would hit everybody. I really want to fix that issue before we just enable it across the board by default.
It does save that as a user preference, so once you do enable it in documents, for example, it will be enabled in presentations, it will be enabled in spread sheets, and it will stay that way until you shut it back off.
The other piece is that specifically with JAWS there is some configuration that you have to do with JAWS itself to get it to let us do what we need to do on the application side, because it really wants to look at Docs as a form, it wants to have the virtual cursor there. All of these things basically make it so that we’re not getting the keyboard that we need to work and it’s not listening to the live region updates that we need to communicate changes back to you.
Derek: I think you mentioned off the top that you’re really targeting the most recent version of JAWS, so right now you’re basically targeting JAWS 14?
Derek: Here’s a question. At some point JAWS 14 wasn’t the most recent version, so at some point JAWS 13 was the most recent version. Were the things that you were doing back then, or the type of work that you’re doing right now, was there any point in time when JAWS 13 was the most recent and it was working in that scenario, or has it been something that’s just sort of more recent with JAWS 14?
Shawn: It was working with JAWS 13, however there were inconsistencies in how it worked with live regions between 13 and 14. When 14 actually came out we had to update our end so that it would work with 14 because Docs would just stop working until we fixed that bug. Also, there were some inconsistencies with how it would get up and running, so it was incredibly to have a consistently good experience with JAWS 13.
Derek: Right. I think it’s difficult to have a good experience with JAWS in many cases in the first place, so that’s not necessarily something that’s completely unexpected.
Shawn: That’s very true.
Derek: I guess I’m sort of wondering at what point if things are working reasonably well now with JAWS 14 and they’re not compatible with JAWS 13, we’ve still got a group of people that are potentially left out because they can’t use their particular version of the screen reader because they haven’t an upgrade authorized yet or things like that.
I’m also thinking about what happens when JAWS 15 is the most up to date and most modern. Is that something where you’ll continue to support what you currently have in 14? Will it be that you’ll be supporting more than just the most current moving forward, or has that even been decided yet?
Shawn: We follow pretty much the same stance with browsers, so it will be the most recent couple of versions. When JAWS 15 comes out, that doesn’t mean that 14 will suddenly stop working. It’s the same with 13; it should still work fine, it’s just not going to be as smooth of an experience and it’s not going to be where the bulk of our attention is put.
Derek: Okay. So we get a baseline level of working, but it may not be as enhanced or as smooth as the most up to date version.
Shawn: Right. We also try to keep our documentation up to date, as far as how to get up and running with different screen readers. For Docs, as an example, we have a page that outlines exactly the different kinds of things that you need to do for each of the screen readers because the set up for JAWS obviously is not going to apply to the set up for VoiceOver. As new versions come out we try to keep that up to date so that if there are any changes in that process we want the users to know exactly how to get up and running.
Derek: That makes good sense. I know that’s something that we’ve tried to balance in the work that we’ve done. We’ve done quite a bit of work on some reasonably complex web apps as well, and one of the things that we always try to do is provide those orientation guides just as much as we provide help so that people know to go in and review this information before they try things instead of waiting until they’re getting stuck. I think that’s a pretty forward thinking way to approach it. It’s really good to hear that you’re doing that.
We’ve only talked about screen readers so far, and that’s really just one type of assistive technology. I’m curious to know if there are things that you’re looking at with other assistive technology. I know we see a lot of other assistive technology in our work when we’re working with people with disabilities and clients that have people with disabilities on staff that are using different pieces of software.
I’m curious to know how things work or if you’re at the point yet where you’re really focused on the screen reader side of it because that’s such a huge need. I’m wondering about things like Dragon Naturally Speaking and voice recognition software, and how people with different mobility or dexterity impairments would fare with using Google Docs with their assistive technology.
Shawn: There are a few different things that we’ve been looking at. I obviously can’t say, “We will support this in the future on this date,” or anything. Specific features and dates, I can’t really offer.
I do know and I can say that Braille displays, for example, you can technically use Braille displays with Docs. It’s not something that is completely supported right now, so the experience is definitely not ideal.
Screen magnifiers pretty much the same thing. Part of the issue there is that the blinking cursor that you see on the screen is not an actual cursor, it’s a div that’s going on and off, which screen magnifiers don’t really have much that they can hang onto at that point. We’re working on those challenges.
As far as speech recognition, that is something that we are working on. I’m not sure what the timeline is or exactly how that will work. I’m not working on that one specifically, but I do know that it is being actively worked on.
Derek: That’s good to hear. It’s something that we’re certainly seeing a lot more of. Given the massive amounts of time that everybody spends behind computers, there’s more and more cases of repetitive stress injuries and carpal tunnel syndrome and things like that.
I know I’ve made use of it myself in the past when I’ve had an injured wrist from doing too much gardening and things like that. Having access to be able to create a document with voice recognition technology is good, but also being able to command the menus and all the different functionality that’s on the screen with voice recognition software is of huge importance to the people that rely on it.
I know one of the things that we’ve seen in the past, I know we’ve looked at Google Docs and I know that in many cases we uses ARIA to create buttons and have buttons on the screen, even in Gmail the compose new message button isn’t actually a button, it’s usually a span or something that’s been styled to look like a button, and then in the proper way, given some button like properties by using things like ARIA’s role attribute.
One of the challenges that we face and something that I’m hoping you can take forward to the team, if they’re not already working on it, is just the use of plain old buttons. Only because the ARIA buttons right now, or a span or a div with the role of button, doesn’t really give any access to anybody other than screen reader users. A voice recognition user, if they say something like “click button,” the voice recognition software doesn’t actually recognize those fake ARIA style buttons as an actual button and it makes it much more difficult for them to use.
Hopefully that’s something that can be worked into the mix somewhere. I know that’s probably a point of contention that has been brought up before in the Google Docs and Google Apps world. I’m interested and hopefully we’ll see some progress there. I’m not sure if you’ll be able to talk about that during AccessU in your session or not, but that would be on the top of my mind.
Shawn: That was something that I was planning on bringing up, just because with the different toolkits that we use they do tend to like render things as divs, role button with spans in the middle, and have everything be fake but acting like it.
However, because it’s built into the toolkit itself that way, it’s a little more difficult to “change the world” as far as that goes. Changing the Docs world I can pretty much do from here, because that’s where I work. But changing the entire Google world takes a little more.
Something that I would like to see is the assistive technologies that don’t currently recognize ARIA having some better support in there.
Derek: Absolutely. I know that’s a limitation of voice recognition software right now. Unfortunately, it’s a limitation. I wish that it was something where they got on board and started implementing ARIA support for things.
Shawn: I could imagine that it would be very helpful also if you’re in Google Docs and you have the font dialogue open, say you’re adding some fonts to your document, once you’ve selected things being able to say, “close the dialogue,” and have it go, “Okay, you have a dialogue open so I’ll close that.”
Derek: I think we would all love that. I guess that’s where we sometimes see a conflict between technologies. Just as you said, it’s much more difficult to change the toolkits in the entire Google world, you really only have a domain of control. Exactly the same problem is faced with assistive technology vendors and convincing them and having them work on this type of stuff is probably just as big of a challenge as changing stuff at the toolkit level.
Derek: I love the way you phrased it, to be honest with you, that changing the world is much more difficult. I believe that that’s the kind of things we’re doing anyway, we’re trying to change the world here. I think that’s kind of the appropriate way to think about it. Nobody said that it was impossible, just that it was going to be hard. Let’s definitely both keep working on that front.
Derek: Some questions about Austin, Texas. You were based in Austin for several years, correct?
Shawn: I was, yes. I lived in Austin a couple of times. I lived in Oakland in between. I was in northeast Austin for about five years.
Derek: Excellent, so you’re familiar with Austin.
Shawn: I am, yes.
Derek: One of the things that we’re trying to do is get people’s advice, because there are a lot of people that come to AccessU that are not from Austin, they’re from all over the country and in many cases all over the world, we have people fly in from overseas even. If you could pick one thing, what’s the one thing that you would recommend to people that they do or see while they’re in Austin? And don’t say the bats, because we’ve already had that one and we need some variety.
Shawn: I’m sure the bats and the barbecue have both already been mentioned. For myself, one of the nice places that I like to go to in Austin, which it’s hidden fairly well but once you find it The Elephant Room is very nice to check out. They have some great jazz going on down there and a nice little bar. It’s just tucked away downtown. You’re going through downtown Austin and you go down and there’s this just really nice environment to hang out and have a drink.
Aside from that, Veggie Heaven I highly recommend to anybody. It doesn’t matter if you’re a vegetarian or not, they have extraordinary good food.
Derek: That sounds fantastic. Are you planning on going to those places while you’re in town for AccessU?
Shawn: If I can swing it, yes. I’m hoping to.
Derek: Okay. I’m wondering should we give the addresses to people. But if we do, does that mean they’re going to be overrun and you won’t be able to get in at either of the places?
Shawn: Veggie Heaven tends to be fairly popular, so if we show up with a crowd of 20 that will be most of the restaurant, I have a feeling.
Derek: We’ll post links to both of those places – Veggie Heaven and The Elephant Room – in the show notes and in the transcript.
I wish I could be there at AccessU, it sounds like your session is going to be great.
I hope everybody else agrees. It’s definitely a complex problem and it sounds like you have some good people working on it. I love the way that you’re thinking about accessibility and your philosophy.
Thank you so much for taking the time with us today, I really appreciate it. Enjoy your time at AccessU in Austin.
Shawn: I appreciate it. Thank you.
Derek: Make sure you catch up with Shawn and all the other great speakers in a few weeks in Austin. Again, its AccessU — get all the details at knowbility.org
– that’s k n o w b i l i t y dot org.
Links from Shawn’s Interview and Helpful Resources for Google Docs
Veggie Heaven: http://veggieheavenaustin.com/Veggie_Heaven_Menu.php
The Elephant Room: http://www.elephantroom.com/
Google’s general support guide: Google Apps for Blind and Low-vision Users
Google Docs screen reader start guide: Use Google Docs with a Screen Reader