Project Demodocus: Bringing Accessibility to the Masses

Trevor Bostic (Left) and Jeff Stanley (Right). Photo by: The Demodocus Team

Interviewer: Cameron Boozarjomehri

Welcome to the latest installment of the Knowledge-Driven Podcast. In this series, Software Systems Engineer Cameron Boozarjomehri interviews technical leaders at MITRE who have made knowledge sharing and collaboration an integral part of their practice.

Every year, countless Americans with disabilities interact with government resources for everything from receiving benefits to registering to vote. But not all websites are created equal, and even fewer are designed with the disabled community in mind. Enter Project Demodocus, a new automated approach to test websites of all kinds on how usable they really are for those who need more than just a keyboard and mouse. Join us as Demodocus Project Leads Trevor Bostic and Jeff Stanley guide us through the complicated world of Section 508 compliance and what MITRE’s doing to make the internet a better place for people with disabilities.

Click below to listen to podcast:

Podcast Transcript
Cameron:	00:15	Hello, everyone. And welcome to MITRE’s Knowledge-Driven Podcast, a show where I, your host Cameron Boozarjomehri, have the incredible fortune of interviewing brilliant minds across MITRE. Today, I’m talking with Trevor Bostic and Jeff Stanley of the Demodocus Project. Trevor, Jeff, would you like to introduce yourselves?
Trevor:	00:31	Hello everyone. This is Trevor Bostic. I am the principal investigator for the project we’ll be talking about today. So, we’ve given it the pet name Demodocus, but it’s really all about automating accessibility testing for dynamic web content.
Jeff:	00:46	I’m Jeff Stanley. I am a systems engineer here at MITRE and Trevor’s co-principal investigator.
Cameron:	00:53	I think my first real question for you guys is, what is Demodocus? What does it mean? Where did it come from? What is this project?
Jeff:	01:02	Demodocus is the name of the blind bard in the Odyssey, and we thought it was a fun name that we could use as the shorthand for this project.
Cameron:	01:09	And what is the name of this… This is an awesome project, but if I recall when you sent it to me the first time it had a rather unwieldy name.
Trevor:	01:16	So the full title of it is the Automated Accessibility Testing of Dynamic Web Content.
Cameron:	01:23	This is a really interesting project to me because, as part of producing this podcast, I have to be section 508 compliant, and you guys are directly working to help different sponsors and agencies with this exact kind of problem. So maybe you could start us off by talking about what really this problem is that inspired your work.
Trevor:	01:43	So the problem we really started with was working with sponsors, and a lot of them are trying to move their websites to become more accessible. So they want the different offerings that they have to be available to everyone, regardless of their ability. That’s a very noble gesture. The problem came when they started to actually implement these into their workflows. It quickly became apparent that a lot of these online web applications needed a lot of remediation in order to become accessible.
Trevor:	02:13	So there was a question of, how do you make them accessible? Do we have developers with this experience? Do you hire just accessibility experts that are supposed to come in and kind of test your application, tell you what to do, and then you go back, your developers work on it and you repeat that cycle over and over?
Trevor:	02:33	So, basically, what it comes down to is there’s just a lot of manual effort involved. If you need people to test it, those people need to tell the developers what the problems are, and then every cycle you have to redo that again, because you now have new accessibility problems.
Trevor:	02:49	One of the solutions to that was automated tools. They cover about 40% of accessibility issues now, and they’re very consistent, but they cause issues that they only get that 40%, and you still have to include the manual amount of work in there.
Cameron:	03:06	So, if I can elaborate, something I want to understand is, what are the things that they’re typically implementing on these sites to help people with disabilities or people who have difficulty interacting with these services?
Trevor:	03:17	A lot of the things are built right into the browser and right into regular code. Those might be HTML attributes—they’re attributes that are meant to go and connect with assistive technology so that the technology knows how to interface with it. For instance, you might have a dropdown that has a particular role that might be like list box or something. And when a screen reader gets to that, it’ll read it out in a particular way that that user can understand and gives them a frame for what interactions they can expect from that web element.
Cameron:	03:50	And so this is the part where your project comes in because you guys have been working to build tools that they discreetly go and just do this stuff, right?
Trevor:	03:58	Yeah, exactly. The current state of tools that we looked at falls into a couple of different buckets. So you might have static tools that go into a webpage and do what we call static analysis, and that’s where they go and look at the HTML of the webpage, perhaps the SCSS as well. They essentially look at the different attributes that are given to all of the elements in that page and, using that, predict if a user were to come onto the site, would they have a good experience? Would the correct things be read off to a screen reader? Would a keyboard user maybe be able to actually interact with something?
Trevor:	04:35	The problem that we’re addressing specifically is that those tools are really only able to guess if that’s going to actually work, because they’re not interacting with the page at all, and so the gap that we’re trying to fill is to actually go onto these pages and try to simulate what a user would do. So we would go into those list box and instead of just looking at the code and trying to predict, well, this will probably work, it looks like it has the right attributes, we actually try typing things in or pressing the keys and seeing what the results of that interaction is.
Trevor:	05:08	You could think of it as testing the JavaScript of the page, which is often where accessibility issues may lie, but are really difficult to test.
Cameron:	05:18	I think this might be an opportunity for one of my patented metaphors. I’m sure a lot of people who are programmers are more familiar with this, but to a lot of people who don’t spend a lot of time developing websites, just imagine a paper form where you just have the fields, and you write down the information in those fields and then when you hand it to someone, that’s basically the webpage taking that information and sending it off to the server. And that’s, for the most part, how websites would take in this kind of information for the longest time.
Cameron:	05:45	But nowadays, with JavaScript, with this ability to have websites that rearrange themselves and can pull in new data and do things based on what your input to the previous field was, suddenly the way that you can analyze what’s on the page is different, because before, the HTML was literally just looking at the form, you could see the form, you could see the fields in the form, you knew what was there, but with JavaScript, all right, now that I’ve clicked this button, suddenly new forms appeared that were not in the HTML or not in the Dom or whatever system they’re using to express what’s on the page that are suddenly there, that my tool couldn’t read before. And that, as I understand, is where a big part of the problem was.
Trevor:	06:27	Yep, exactly. Just to add onto that a little bit, this is a known problem within the accessibility community. A lot of those current tools, if you test them on the entry state of the page, so you go onto that first form you were talking about? Once you click that, if you run the tool, and it says everything’s all good and then you click the button, the tool will then tell you, hey, you also need to run the tool on this state as well to see if there’s no accessibility issues here as well.
Trevor:	06:56	So every time you interact and that JavaScript brings new content to the page, you have to rerun the tool to make sure the new stuff that’s brought in is actually still accessible. So it has this compiling factor of how many different times do you have to test the same page to feel confident that it’s truly accessible?
Cameron:	07:13	I love this, and I want to dive a little more into it because it’s one of those things where when you think of new technologies, you think of all these things, you think of it as bettering everyone, but there’s a large part of the population that they have seeing, hearing, any number of disabilities that make it hard for them to interact with technology like you and I might, and there’s a real need for these technologies and tools. But as new tools come along, like I, having done web development know how quickly the landscape can change. Next week you’re going to use a different JavaScript library or a different API or whatever thing you’re going to do, which means that you’re spending so much time trying to make sure the technology works for the typical user, you’re not thinking of the other people who are considered edge cases, the people who…they are sometimes even more important to think about in the design of your system, but their needs are so different from what you’re used to developing for that it’s hard to keep them in mind when you’re doing system requirements.
Trevor:	08:13	Absolutely. One thing that we find a lot is that people would develop a website, and then at the very end, they’ll bring in accessibility experts and say, “Hey, we’ve gotten the website pretty much completely done, what little pieces do we need to patch on to make it accessible?” And a lot of times the response is, you might need to just start almost from scratch, because what you’ve put here is in such a bad shape for someone that has a disability, that’s using a screen reader or something else, that it’s practically unusable to them.
Trevor:	08:44	A lot of times we see in government that this ends up where they try to get waivers because they’re like, we can’t do that. One of the goals of our project is we’re trying to push that back further into the development pipeline so that essentially when you start developing on a web application, you can start doing that with this tool in your back pocket, and every time you get to a new version, you can run the tool on it, it’ll hopefully help to see if it’s accessible, and you can start to build that in to your web application as you go.
Trevor:	09:13	This is all trying to help that making sure that the disabled community has access to all of those new tools, all of the new technology, as everyone else does, instead of them having to wait for 5 or 10 years to have the same kind of experience and access that everyone else does.
Cameron:	09:29	It’s actually funny to hear that this is a problem that you hear impacting all the different parts of development. You think about this when it comes to security, when it comes to data collection and data privacy. It’s interesting that this continues to be something that we are always trying to build a more ubiquitous view for when we’re designing a system so that it doesn’t become an afterthought, like you mentioned.
Cameron:	09:51	One place I would like to segue too, though, is maybe you could speak a little more to the different ways you are helping. I know you mentioned you want to build something that lives in the browser that can help with this kind of work, but maybe you can elaborate on the different places where you’re hoping that this kind of work can impact people.
Trevor:	10:08	Sure. Maybe I can talk a little bit more about that tool here and specifically what it’s trying to address. As I mentioned, a lot of the testing is currently done by manual experts, and the reason for that is a lot of the current tools can’t test any of the interactive content on the page, so all that JavaScript that we were talking about really has no way of being tested except for a manual expert.
Cameron:	10:29	And if you don’t mind me interrupting, a manual expert is?
Trevor:	10:32	Someone that has been specifically trained in the accessibility regulations and knows what to look for. They know the different tools that they can use in order to actually test the pages for different accessibility issues, how to classify them, potentially how to fix some of them. Though generally, there are few accessibility experts that are also developers.
Trevor:	10:53	So our goal is that you have these static tools that can run on your HTML code, the static portion of it, but then there’s also this dynamic portion that’s untouched except for those manual accessibility testers. And we’re really trying to fill that gap where we can go in and as you’re creating these different experiences, these different user workflows, for your web application, that we can exercise those and test them for accessibility as you’re going along. The idea being that if we can have an automated way of doing this, you can imagine putting this in your CI pipeline and coming in every morning and it going, “Hey, you know that a form you created yesterday. Well, we found out that one of those buttons can’t be reached by the keyboard, so you should probably go and fix that.”
Trevor:	11:36	And that brings it full circle, in that we have, when you’re thinking the agile cycle, there’s this continual churn and getting better, until you get to that final product that’s already been tested for accessibility so many times that hopefully the end product is quite accessible and quite usable by the disabled community.
Cameron:	11:53	That’s really great to hear. And now I’ve got to ask, is there anywhere that you’ve been able to apply your work? Anything that you can speak to directly where people are ideally already reaping some benefits from your hard work?
Trevor:	12:03	So we’ve tested it on several public facing government websites. Specifically, the one that we’ve actually had some pull with as we tested it on our own homepage at MITRE, and were able to find out that our actual navbars were not able to be accessed by the keyboard. So we reached out to those folks and they were able to fix it pretty quickly. It was nice to see that we were able to actually get it to run fully on a webpage, it performed as expected, and then we were able to communicate that and get it fixed.
Cameron:	12:33	I love hearing that because this is really getting into the territory of why this really matters. It’s one thing to say, what are really the things that you expect people to interact with that it’s not such a big deal that someone interacts with the navbar on MITRE’s webpage, but when you think about the kind of government services…this is something that ideally helps with government. And part of what I like about your work is it’s not something that requires any sort of special going behind the scenes, doing anything top secret. It’s really just this public facing component that people are supposed to interact with as part of the design of the website is what you are testing so that you can tell people in government: this website doesn’t work. People who have disabilities and need resources, especially now where we’re all locked down and all in dire need of whatever things we need, is important that people be able to access those types of websites and get the resources and help they need.
Trevor:	13:23	Absolutely. Although, I do want to pull one thing back. One of the things that we definitely try to pay attention to is not just accessibility in the form of regulations, but we even try to tackle the usability side of webpages a little bit as well.
Trevor:	13:36	For instance, if you have a page where a user needs to maybe tab five times to get to the link that they’re interested in, you’ve probably made a pretty good workflow. They’re probably going to continue to use your site. Whereas perhaps those pages were still able to be accessed, but they were all the way down in the footer and it might take someone a hundred tabs to get there. Well, they’re never going to actually do that. So we try to take that into account somewhat, and that maybe it’s not breaking regulation, but you’re still creating such a poor user experience that it’s what we might call technically inaccessible. It might function, but it’s not really going to be usable by the community.
Cameron:	14:15	That’s extremely important to keep in mind. Usability is fundamental to whether or not anyone’s going to be able to go do the things they’re supposed to do to get the things they need. I guess the next question is, is there anywhere we can go to learn more about the work you’re doing, or if there’s any specific sponsors or anyone you’re hoping to work with?
Trevor:	14:31	We were accepted to CSUN, which is the Conference on Accessible Technology that’s over in California, unfortunately, due to COVID that got shut down and we weren’t able to actually present there.
Trevor:	14:45	As far as published materials, we have some background lit review that we’ve published on archive, and we are currently proposing or submitting to several other conferences and hoping that we’ll be able to present later this year and maybe early next year. So those will be the biggest, at least academic press releases for this project.
Trevor:	15:05	We are also planning to open source this project by the end of this fiscal year, so somewhere around the end of September to October, and that will allow everybody to hopefully go and actually inspect the code and run it on their own. That’ll be the other big thing to look out for as well.
Trevor:	15:20	We have several government sponsors that we’re continuously in talks with that we go and show them and we try to understand what their problems really are. Although always keeping in mind that though this is a lot of times phrased as a government problem because of section 508, we really hope that it ripples out into the private sector as well, because this is a global problem. It’s not just you only need to access government resources. There’s a lot of people in the disabled community that are trying to access Google resources, for instance, and may not have access to it.
Trevor:	15:51	Ideally, what we’re hoping is that when we open source this, a lot of the different accessibility technology companies that exist right now will hopefully be able to take it and maybe not use it directly, but at least try to figure out the ideas that it represents and integrate that into their own testing tools so that this technology starts to become more pervasive, and we can start to break above the ceiling, because the current state of automated testing tools has remained a little stagnant.
Jeff:	16:20	Can I add to that?
Cameron:	16:21	Yeah, go ahead, Jeff.
Jeff:	16:21	A lot of people from within MITRE and our sponsors have been reaching out to us, people who see what we’re doing, and they’re also interested in automated accessibility testing or automated usability testing, and we’re seeing a community forming around that. And it’s very gratifying to be on the cutting edge of that community. It’s exciting to think about where that’s going to go within MITRE in the next year or two.
Jeff:	16:47	There’s a mantra in the accessibility community that when you make something more accessible, you’re really making a better experience for everyone. So for instance, if you’re trying to operate a piece of technology in the dark, you are temporarily a low vision user, so it’s important to note that this is not just helping a subset of the population. When we think about accessibility, we can really be helping the entire population.
Jeff:	17:15	I had a baby in March. When I’m holding a baby, I’m looking for ways to do everything one handed, so I’m more sensitive than ever to the plight of not having one limb when you’re trying to do something.
Cameron:	17:27	I think that’s a really beautiful sentiment to go out on, Jeff. And to that end, I’d like to quickly think MITRE and the Knowledge-driven Enterprise for making this conversation and this show possible. And a big thanks to you, Trevor and you Jeff, and the entire Demodocus Project for sharing your incredible work and helping improve the lives of countless people in our country.
Trevor:	17:46	Thanks for having us. We really appreciate being here.
Jeff:	17:48	Thank you, Cameron.

Cameron Boozarjomehri is a Software Engineer and a member of MITRE’s Privacy Capability. His passion is exploring the applications and implications of emerging technologies and finding new ways to make those technologies accessible to the public.

MITRE’s mission-driven team is dedicated to solving problems for a safer world. Learn more about MITRE.

Justin Brunelle: Lessons from MITRE’s Innovation Program

Rachel Mayer on the Fight Against Maternal Mortality

Theodore Wilson: Thinking Like a Turtle

Marcie Zaharee and MITRE’s Open Innovation Challenge

Dan Frisk and Paula Randall on bringing innovation to government

Interview with Julie McEwen on why privacy is key

Interview with Awais Sheikh on Deciphering Business Process Innovation

Interview with Jackie Morin on her journey from intern to senior engineer

Interview with Jay Crossler on why passion is the key to success

Interview with Dan Ward, Debra Zides, and Lorna Tedder on streamlining acquisitions

Interview with Dr. Philip Barry on blending AI and education