PEAT Talks Transcript: Building Accessible Online Recruiting and Hiring Systems

Transcript of PEAT Talks: Building Accessible Online Recruiting and Hiring Systems webinar with Denis Boudreau of Deque held on April 21, 2016.

Introduction

Hello and welcome to PEAT Talks, the virtual speaker series from the Partnership on Employment and Accessible Technology. On every third Thursday of the month, PEAT Talks showcases various organizations and individuals whose work and innovations are advancing accessible technology in the workplace. My name is Christa Beal. I'm a member of the PEAT team, and I'll be hosting this afternoon's talk.

Before we get started, I'm going to quickly review a few logistics. We will have time for the Q&A at the end, so please enter your questions in the chat window, or by e-mailing info@peatworks.org. You can also e-mail info@peatworks.org if you are having any technical difficulty. You can download the presentation for today's event on peatworks.org and an archived recording will be posted online following today's event. We will be live tweeting today's event from @peatworks, so please feel free to join us and follow along using the hashtag peattalks, with two Ts, and including @dboudreau. d-b-o-u-d-r-e-a-u.

Today PEAT is honored to welcome Denis Boudreau. Denis is a Montreal-based senior web accessibility consultant and strategist working for Deque and an invited expert of the World Wide Web Consortium, participated in various working groups. He has been advocating social inclusion on the Web since 2001. Today Denis will be talking about why accessible e-Recruiting tools makes sense and the simple steps that web developers and designers can take to ensure that job seekers with disabilities are not excluded from employment opportunities. Denis authored a blog on the topic for PEAT in February, and we are looking forward to delving deeper into this topic today. Now, without further delay, I will turn things over to Denis.

Presentation

Thank you very much. Thank you everyone. I'm very happy to be here. Can you guys all hear see my screen? You should be seeing a virtual picture of —

Yeah, we got it.

Okay. So, as you can see, we have a picture of a bunch of people about to listen to someone speak, and that would be me today. It also was me about ten years ago, as I was involved with a group in Montreal that are working towards helping people with disabilities find employment. So the topic today is really not new to me, somewhere around 2006, or maybe 2007 it was, I got involved with that group in Montreal. And I was invited to speak to their vendors, because they were trying to put together this solution to help Montrealers, and people from Quebec, actually, that had disabilities finding jobs using technology, because technology was this thing that was becoming very exciting and that could yield extraordinary opportunities for people with disabilities when it came to finding jobs.

And most of the people that were in that room were either developers, designers, or business stakeholders that were involved one way or another in building technology that would help support those goals, and none of them, or very few of them, had ever heard of accessibility before. Most of them have never even considered the fact that people with disabilities would want to use a computer.

So, as I was going over the issues that people with disabilities were having, trying to find employment back then, I could see that people had puzzled looks on their faces and didn't really see where I was going with that stuff, because, as most people back, then thinking about someone who is, for instance, wanting to use a computer was pure fiction. And at some point one of the people in the room raised their hand and very innocently said, told me that, in a way, people that didn't have a job back that, or people that don't have a job, they had to either be lazy or lack of motivation, because in a world where technology makes it so easy today, yet you can't really understand why they wouldn't be able to find one using the technologies that were available. And back then we weren't talking about social media or anything like that, we were just talking about job postings on websites, and sites like monster.com were barely emerging as new thing. So to them it was really — what I was talking about was really something that didn't make much sense.

If you wanted a job, the Internet had tons of them, and if you were motivated enough, you would find one. And it's interesting to me too, when PEAT reached out to me and we started discussing this article I wrote a couple months back, it brought me back to that moment about ten years ago, where I had to research that stuff and try to work with people to make them understand what needed to be done.

And as I started researching all the issues that we still had today, I was very surprised that things hadn't improved that much. And, as most people would think, when you think about technology and everything that has evolved in the last ten years, you would think that it should be easier, but in reality it happens to be the opposite. We really struggle quite a bit still with that stuff. So this is what I'm going to try to talk to you today about.

So what I did, basically, was I did an overview of some of the websites that are available and see how accessible they are, and then we'll walk over those findings together. So very quickly, that would be me working with Deque Systems, involved with knowbility, which you may know last month's excellent speaker was Sharon Rush, and she's from Knowbility and mostly involved with things at different levels. And I want to start with this.

So the Bureau of Labor and Statistics, in June of last year, said that about two in ten people with disabilities were part of the labor force in 2012, and they were comparing that with seven out of ten — with people with disabilities. So we can clearly see that if you do have a disability you're much less likely to have employment in the United States, so, as a starting point.

And then as I was looking over some of those statistics, I found the statistics.org site, and they had that information, which I thought was staggering. So back in 2000, where we didn't really have technology that supported job search that much and people were still very much looking into newspapers and had board posts and stuff like that, we had about a fourth of the people with disabilities that were employed, so 24.4% of people with disabilities in 2000 had a job, whether it's full time or part time.

And if we look at the statistics from 2014, which was the last year that they had, that number had dwindled down to 12.9, so almost 13%. So we can see that, year after year, it just kept going down, and going down, which is very surprising, again, because when you look at or when you think about the innovations in terms of technology, it is much easier than it used to be to find a job. We have way more options to do that.

Social media has only improved on that in a very significant way, yet we have more options, but people with disabilities are less and less employed. So there is a really big issue behind that.

And I think that the reason why that is is not — it's definitely not because people with disabilities are not interested in finding employment. As a matter of fact, it turns out that 66% — or 67% of them are motivated into finding one, but they actually struggle with finding a job. And some of the statistics that I'm giving you right now are documented at the end of this slide deck, so you'll be able to go and see that afterwards.

But, out of memory, about two-thirds of them would want to go find a job but they just can't find one. And I think most of the reason is based on the fact that people who actually developed these systems, these platform, these solutions are not aware, still, ten years after that experience that I had, still not aware of accessibility, and users with different needs when it comes to using technology, and I think that's one of the very important reasons why that is, why it's more and more difficult. Because if you don't have any job openings that are offered in traditional ways anymore because everything is converted to the Web, and it's not surprising that if your Web is not accessible, that people won't be able to find those jobs. It kind of makes sense.

So I think we have a responsibility, as people who are creating those applications, to make sure that they do meet the needs of the largest possible number of people. Otherwise — yeah, otherwise why would we bother building them in the first place. I mean, the IT industry is to provide people with opportunities, and we're clearly not doing that when we create inaccessible solutions.

So as I said, I looked at some of the most interesting or more popular websites and I decided to assess them based on reasonable criteria. So accessibility reaches much more broadly than just this, but I decided to look for keyword access, images, forms, contrast, and text resizing, and basically would I be able — as someone using the Web, would I be able to use the whole application using only my keyboard? Would all the images be informed in a way that conveys all the information that those images convey? Would I be able to hear about the different labels when I walk through a form using a screen reader? Would the contrast be sufficient for me to be able to distinguish or perceive information off the screen? And what happens if I happen to need to bump up that font because it would be too small? Are things going to be readable or legible still? Or am I going to start experiencing an interface that breaks down and stuff that gets over lapped or truncated and stuff like that; meaning that I couldn't be able to read some of it, or none of it.

So, looking only at those five very simple metrics, I tested that against what appeared to be the most popular websites as of today, and I found that site ebizmba.com, and they had this flag post where they talked about the 15 most popular job websites as of April 2016. So I figured that was very recent information, and the five sites in question were, Indeed, Monster, GlassDoor, CareerBuilder, and SimplyHired. So I ended up looking at all five of those websites and measured them against the five criteria that I just talked about.

And basically what I found was that, looking at keyboard access, for instance, when I would test each of those sites, the only one that would really work in terms of keyboard accessibility was indeed.com. And all the other four — monster.com, glassdoor.com, careerbuilder.com, and simplyhired.com — all broke at one moment or another as I was trying to use the keyboard. Sometimes I would not be able to reach a certain element. I would just skip over it without any reason and I wouldn't be able to select a specific form control for instance, or some of the stuff just wouldn't be available or would not display to me using only a keyboard. It would display if I used the mouse, but it wouldn't if I used the keyboard. So there were issues that prevented me from fully accessing the content using the keyboard.

Then I looked at images. Again, indeed.com succeeded in describing the one image they had, which made it pretty simple. But in all the other cases, the sites failed to describe or deliver relevant information or relevant description to each of the images that they provided that conveyed informative content. When it came to the forms, none of them were able to do that. So there was always something, whether the form fields didn't have an X label that was associated with the field, so you wouldn't know what the field was for, or sometimes the associations were a little sketchy, so you would have to guess whether or not what they were expecting, so you wouldn't really be able to make sense of it.

When it came to contrast, same thing, they all had issues whether it was with the text against the background or maybe links, around things around the surrounding text, it was more difficult to distinguish those links — those contrasts. In terms of text resizing, again, Indeed managed to do that properly. The other ones didn't.

Now looking at this, you can clearly see that monster.com, glassdoor.com, careerbuilder.com, and simplyhired.com, even though they are four of the five most popular sites, all basically may seem like it's doing well, if you can see that. That there is a screen capture of indeed.com, and it's basically a two-form field [indiscernible] make up those. That's basically all there is to it.

So, obviously, if your design is simple, making sure that it works well with the keyboard is that much easier. You don't have to consider as many things. So there is a correlation to be established between these views of your keyboard and the complexity of your design to begin with. That's clearly the case. If we compared, Indeed with, say, for instance, monster com, where we have a more conditional interface with a lot more content, making things work well with a keyboard here should be a little more complicated than it is with Indeed, because Indeed really has very little content on that page.

But at the same time, if you think about accessibility from the very beginning, as you build your product, it's not that much more complicated. If you're developers understand what they need to do it's not that much more complicated. You just have to pay attention to it. Just like you have to pay attention to like designers, for instance, will look over the developer's shoulder and make sure the look and feel is exactly what they designed in Photoshop or in their mockups, and everybody's aware of that so they pay attention to that stuff.

If developers knew about keyboard accessibility, they would do that as part of their development. It would be part of their QA before they even hand it out to other people. So the complexity of the interface, in reality, shouldn't be an issue with accessibility, because if you know about it, you test for it as you build, and if you do that, there won't be any issue when you're ready to release it to your other team members or your QA folks for instance.

All right. Great. So we got a question in about tips, guidelines, recommendations, and tools, and I know there are a lot in this presentation, especially if you download the full slides and look at the appendix and then, you know, PEAT just introduced TalentWorks, which you can find on peatworks.org. And I'll let Denis answer if there's any other tips and recommendations and tools.

So the question is about what tools to use, or tips?

Yeah, like tips, recommendation, and tools for kind of implementing some of these ideas.

Well I think that the most interesting thing to consider to begin with — because there are a lot of things to consider obviously, but as someone who may not be an accessibility expert to begin with, you need to find tools that will allow you to, like, find the low-hanging fruits really quickly, and that doesn't have to mean being technical. It doesn't have to mean looking at source code that much to do this. And quite frankly, assessing those sites took me about 30 minutes total, because all I did was use two different tools.

There is a tool that Deque developed, the company I work for, that developed a tool call "aXe," and it's basically an extension on your browser, whether it's Chrome and by launching that analysis, it will tell you those low-hanging fruits, what are the things that don't work on the website from an accessibility standpoint, things that can be automated and won't return any false positives. So it's stuff that you can easily look at and go back to your developers or vendors, for instance, and say we're supposed to be talking about developing an accessible site, yet, I run this very simple test on the site they're developing and I finding all these different issues here. Why is that?

So a tool like aXe tenon is a competitor tool to aXe, but it does basically the same thing. They're both really, really good tools. They don't look at the same things the same way, but they basically find the same problems, which you can validate that they're both interesting websites they're reliable in both cases. In both cases they're tools that you just add to either Firefox or Chrome, and you just run that test by clicking a button or just, like, triggering the test, and you wait until you get all the results. The tool sparks the page and they'll come back to you with stuff like, we found images that didn't have text on them or we found errors in the source code about, like, association between forms and labels for instance. We found that so many labels in the form weren't associated with a particular text field for instance.

So stuff that you could definitely spend time looking into from the source code but that would be in a way, a waste of your time, because tools can be done for you in your life, and it allows just about anyone to look at very basic things in terms of accessibility and determine whether or not the sites or the page that has those issues meets the expected requirements, and usually when you find images like that using these tools, it just goes to show that there are a lot of other bigger much more complicated issues as well, because if developers can't figure out the simple stuff, chances are that the more complicated stuff hasn't been addressed either. So it's a very good way to just have a glimpse of the level, and more than enough for an office like this, for instance, to be able to tell whether or not the basic recommendations have been met in terms of accessibility. So I would recommend either aXe or Tenon in that sense. I think they're the most accessible tools, no pun intended, accessible tools to just get a glimpse of the current level of accessibility on any site.
 
All right, so we are right at about 2:30, but we do have one more question that I will ask you and then I'll wrap things up. But one of our members asked if you can discuss different ways to look at accessibility when you're looking specifically at mobile browsers like tablets or Smartphones or testing across browsers like Safari versus Chrome.

Specific tools or specific ways to do that?

I think ways to improve accessibility when you are mobile optimized or using different browsers.

Okay. Okay. Well, using different browsers shouldn't have much of an impact in what you're doing. It's basically a resource code, so browsers do have different interpretations of that code every now and then. But like the platitude would be the same. If you go according to standards, it should work in each and every one of those browsers. Now, depending on the tools that you use to test that accessibility, it may not be the case.

If you're using a screen that's a [indiscernible] site, there are commonly approved combinations that work better than others. You will be using NVDA with Firefox mostly, or you will be using it with Chrome, because it's getting better and better. But you would not really use NVDA with IDEs so much, for instance. Or Jaws, you would be using as a — which is probably still the most commonly used screen reader. You would most likely use it IE for the most part, because that's where the best combinations are in terms of compatibility and support.

So, depending on what you're looking for the source coach indicates whether or not things are working well. When it comes to mobile, it's a different beast. As long as we're talking about native mobile apps for instance, if we're talking about issue of content that is just presented in a mobile wrapper, then basically the same tests that we do on a desktop version will still apply to mobile. The only difference, really, should be about how the content is being presented on the mobile interface. They usually will adapt to a different layout to fit the width of the browser window. For the most part, the code remains pretty much the same.

When we're talking about native mobile apps, we're usually talking a different language altogether. So there are different tools to do that. I don't really have a list on hand right now, but there are factors that exist for IOS and Android that would allow you to look at the source code, even though you usually don't have access to that information in a mobile device. But most of the testing when we talk about accessibility assessment for mobile is we'll be using either voiceover, which is the default screen reader available in IOS, so found iPads for instance, or we'll be using Talk Back, which is voice over for Android. And what we'll do is, like, we will present as if we were visually impaired users and we'll just use that software to navigate through the interface and figure out if the images are described in text, the different form elements are assigned a label that provides significant information to understand what the purpose of that block form is. And in many ways, it comes down to exactly the same kind of tests we do when we talk about desktop accessibility. We just want to make sure the images, forms, and keyboards, for instance, will still work.

So keyboarding is a different thing on mobile because obviously you don't use your keyboard. But an interestingly high number of people are plugging into — are connecting keyboard through YouTube to their mobile devices. So they are using the keyboard on mobile, but for other people, just the idea, people that don't use a keyboard on their mobile device, the idea of just being able to tap on different elements and being able to set focus to them, in many ways, is very similar to what we do for keyboards. So if you do your keyboard accessibility right in your desktop device, and we're talking about the desktop content being transferred to a mobile device, then it should still work pretty well. So, yeah, I guess that was a pretty long answer, actually, to the question. I hope that helped.

No problem.

But on mobile using Screen reader, like voiceover talk back is probably the easiest way to do that, but there's a learning curve there also to get to learn how to use those tools.

Conclusion

Well it sounds like we might need to put you on the hook for some additional webinars. But for today we'll go ahead and wrap up. Don't forget, everyone, to join us next month PEAT talk, which is going to be on Thursday, May 19th, at 2:00 p.m. We are going to be sharing outcomes from a recent hackathons event that PEAT moderated in Montreal that combined participants from the World Wide Web and Web for All conferences. It's a team to create accessibility solutions for a learning management system. You can find the registration link for next month on peatworks.org or look for an e-mail from PEAT with more information.

I want to give a huge thank you to Denis for sharing all the insights with us today and for all of you who took the time to join us. Enjoy the rest of your afternoon.

Thanks everyone. Thanks for having me.