The “What,” “Why,” and “How” of Digital Accessibility for Business [TRANSCRIPT]
SOFIA LEIVA: Thanks for joining the webinar entitled, “The What, Why, and How of Digital Accessibility for Business.” I’m Sofia Leiva from 3Play Media, and I’ll be moderating today. And today, I’m joined by Larry Lewis, director of channel sales and strategic partnerships at the Paciello Group. And with that, I’ll hand it off to Larry, who has a wonderful presentation prepared for you all.
LARRY LEWIS: Well, thanks so much for joining us at 3Play, and, again, as Sofia had mentioned, the name of this presentation is “The What, Why, and the How of Accessibility for Business.” My name is Larry Lewis, and I represent the Paciello Group, and the Paciello Group, along with 3Play Media, have begun to collaborate on a number of different accessibility issues. I, for one, having gotten acclimated with 3Play, am delighted to be partnering with such a great captioning resource in the industry, so very appreciative of the time that has been put into setting this up. And I will do my best to make this time definitely worth your while.
Now, there’s a few objectives that I want to cover today. I want to, first of all, define what exactly accessibility is. Everybody talks about getting accessible, and I want to focus on what that actually means. In order to do that, we’re going to need to understand our disabled audience. Who exactly is it that we’re compile– or that we’re actually trying to be accessible and bring our content into conformance for? Who is our audience?
In order to do that, we’ll delve a little bit deeper, and we’ll just take a tour of some of the assistive technologies that are out there that those of us who are disabled actually use to access your content. We’ll talk about three reasons why accessibility is important, and we’ll talk about– and we’ll also focus on understanding accessibility standards, and lastly, we’ll begin to wrap things up by just showing you some free tools and some additional tools that are at your disposal for you to get started.
Before I talk a little bit about who we are at the Paciello Group, I just want to take a brief moment and tell you a little bit about myself. I joined the Paciello Group a little earlier this year. Prior to that, I ran my own business for 12 years. And one of my clients was the Paciello Group, where I did a little bit of subcontracting work for them and so forth, joined them earlier this year to work with organizations like 3Play and other organizations who we work with.
One thing of note– and I say this, just so that you, the audience, understand how passionate I am about accessibility. I am a totally blind user of assistive technology, and it’s because of the different types of assistive technology tools out there and the ability to access various types of applications that I am able to be competitively employed. I’ve been able to run my own business, participate in rolling out different products for this industry, and now I’m able to perform all the different sorts of tasks relevant to my job.
So it’s very easy for me to talk about accessibility because I have no functional vision. And if it wasn’t for these accessibility guidelines, and companies that adhere to them, and then the companies who actually make the different types of products out there that allow me to access everything that you do– your computer, your phone, your tablet, kiosks, different things like that– it would really impact my ability, drastically impact my ability to be gainfully employed. So it’s very easy for me to exude passion as to why things ought to be accessible and how to do it.
A little bit about the Paciello Group– we have been around for about 15 years. We’re one of the leading accessibility firms in this industry. We have the distinction of being owned by a company called the Vispero Group, and the Vispero Group is an umbrella of companies, and many of the other companies that are owned by Vispero Group actually make some of the assistive technology tools that many persons who have varying levels of visual impairments use.
So we have the distinction of being an accessibility firm that is closely linked with different sister companies who actually make the products that access different types of content that is developed. And that puts us in a strategic advantage to determine what is accessible and what needs to improve on the assistive technology tools front. And we’ll talk a little bit more about that distinction as we move along.
We’ll talk about the three components to accessing digital content, and we’re going to primarily focus on the first one today. The design of digital content– that is your responsibility, you and the audience, be it a project manager, a developer, a QA tester, a stakeholder of some sort– that actual design of different types of content that we’re going to be focusing on, that digital electronic content.
Existence of assistive technologies– so without different types of assistive technologies to access the different types of content that you might develop, you could develop all the content you want. But if I don’t have the appropriate tools for accessing your content, it’s really not going to matter a whole lot. So you need to have not just content designers who are up to speed with accessibilities and different development trends and whatnot. You also need to have organizations who create specific types of tools that can access the content that’s being developed.
And last, first and foremost, there is a responsibility of the disabled user for appropriately using the tools that they have at their disposal. That usage can be, A, acquiring the right tools, B, making sure they’re kept up to date, and C, making sure that you’ve had the appropriate training so that you’re able to access information quickly and efficiently. Because I have really applied myself to using assistive technology, I would be considered a power user of assistive technology. I can do things like book a flight or make a one-click purchase on Amazon just about as quickly as any sighted individual can, because I can wield my assistive technology tools and use my accessibility tools to get to where I need to be, do what I need to do, and move on. And that’s very important.
Again, it’s not your responsibility as the developer or the content provider to be in tune with the training needs of your clients, but it is your responsibility to think in terms of, how can we maybe make things a little bit more logical? How can we make things a little bit more usable? And by doing that, you’ll actually end up benefiting all users, I think.
So let’s talk about defining digital access. Now that we understand the three components to accessibility, let’s define it. So it’s very simple. It’s as simple as this. There is a set of guidelines out there called our WCAG guidelines that are actually web-centric, and they are a series of guidelines that are undergirded by four principles that have success criteria under each principle to make sure that those prin– that those guidelines are being met.
So WCAG came about a number of years ago, but it really didn’t make its way into this country into federal law until roughly 20– 2016 it made its way in, but 2017 was when it really became federal law that these specific guidelines were to be met. The World Wide Web Consortium really came up with these guidelines a number of years ago, and they’re constantly being updated.
And what these guidelines do is they provide a framework for developers to create content that adheres to these principles. And we have a number of different success criteria that make sure that these guidelines are being kept. When you get your access to this slide deck, you’re going to have a link here that will take you right to all those specific guidelines. In a nutshell, I have an acronym for WCAG, for the four specific guidelines. Things need to be perceivable, operable, understandable, and robust, and I use P-O-U-R, POUR, as my little acronym for remembering that.
So your content needs to be perceivable, and then there would be some different principles under that that would outline what that meant in success criteria to make sure that you were meeting those specific guidelines. Operable– you need to be able to operate and get to the specific content and interact with it. Understandable– it needs to be logical. And robust– it needs to be in a situation so that as assistive technologies improve and so forth, your content is robust. So there is a lot of information there. There are workshops on WCAG created by, as I said, the World Wide Web Consortium that you can take. There’s no way we’re going to cover all things WCAG.
There are also guidelines and white papers and different types of resources out there, if you’re creating non-web content, how to link back to the success criteria to make sure that WCAG is being up to date. The latest updates to WCAG is WCAG 2.1, which is where we’re at with Paciello. We have a seat at the table. One of our chief technology officers is one of those individuals who sits down and makes sure that everything is in step as we move forward, and it needs to be met. So we’re very fortunate about that.
So we have WCAG overseeing everything, and then we have a number of platforms that we would want to work with. So we have our desktop, we have our mobile environments, and we are actually in the kiosks environment as well. And we’ll talk a little bit about that as we migrate to the assistive technology tools portion of what we have to discuss today. And then we have our environments, so within education.
We have transcends environments here, and that can involve education, employment, and community type settings. So we have WCAG overseeing everything, we have our desktop and mobile, and, as I said, we’re moving into more of a kiosk mindset with manufacturers of different types of kiosks and the electronic content displayed on those kiosks. And then we have our environments, and so we want to be in all these places.
We want to make sure that our schools are sharing content that is accessible, that our employers and our workplace are creating environments where things are accessible, and in our outward facing websites, our outward facing apps, everything that you might use in the community– think about that, everything from social media to some of the shopping apps that you might use. We want to ensure that accessibility guidelines are applied across environments, across platform with specific guidelines that will follow.
Let’s talk a little bit about persons who were impacted by inaccessible type content. Who is your users? Who are your disabled users? And I’ve already mentioned to you that I have no functional vision, but there are a lot of other things that you need to keep in mind besides non-visual type uses. You also need to think in terms of your individuals who have limited functional vision, a little bit of vision, and also individuals who might be colorblind. You also want to think in terms of what sort of contrasts those [AUDIO OUT] who have a little bit of vision and what that means.
Moving away from vision– and this is where I think 3Play does an exceptional job– we have folks who have limited to no hearing, so we have captioning services and audio descriptive type services that are out there. And you have individuals who have a little bit of functional hearing and maybe no functional hearing. We also have individuals who have motor impairments, who are not able to use a keyboard, maybe not able to functionally use a mouse, because they have difficulties with their hands. And so we would want to ensure that our content was coded appropriately. So speech dictation would work well with [AUDIO OUT].
And then learning disabilities– that is probably the largest group, and it’s probably the group running the lightest on as it relates to understanding from a disability standpoint. But people who have 20/20 vision, you still have an ability to access print in a functional way as their counterparts might, and that could be the [AUDIO OUT] and so forth.
So a little bit about the assistive technology tools– we have screen readers, which is what I’m using right now. A screen reader basically reads the contents of the screen and provides alternative ways for accessing that information. So when you sit down at your computer, and you click your mouse, and you log on, and you click on PowerPoint, and you click on your slide deck, you’re doing that all with mouse clicks and moving your mouse pointer and clicking.
I’m not able to do that. I have to use alternative keyboard shortcuts to listen to my screen reader, and then perform the appropriate keystroke that would simulate a mouse movement. Or if I’m using a touchscreen, I can use my fingers to swipe around, listen to what’s being spoken, and double tap on what it is I want to hear or what I want to access or whatever it is I want to do.
So the Vispero Group, who owns us, the umbrella companies that I talked about earlier, has made a product that some of you may have heard of. It’s a product called JAWS for Windows. JAWS stands for Job Access With Speech, and it was actually developed by an individual who was blinded in an accident, wanted to get back to work, and actually, a mathematician who created a way to get himself back to work. It, in fact, has helped just hundreds of thousands of people because of his contributions, and that is how the JAWS product came to be.
We also manufacture a product called ZoomText, and ZoomText is a product for people who have a little bit of functional vision that will magnify the screen. There are also products out there that will allow you to speak to your computer and will respond accordingly. I’m sure everybody’s heard of Dragon. We have a variety of different types of hardware out there– ergonomic mice, ergonomic keyboards, different types of headsets for hearing impairments, in more recent years and so forth, you have Bluetooth connectivity. It actually can connect through a hearing aid into a specific operating system, such as mobile phones and computers and so forth, and actually utilize a hearing aid as a headset to some degree, having things routed through a Bluetooth hearing aid. So all sorts of assistive technology tools at your disposal.
One thing that I didn’t mention back in the user side of the equation is sometimes you’ll have individuals with multiple impairments. You might have somebody with a visual impairment and with only the use of one hand, or you might have somebody with a hearing impairment and a visual impairment. And that can get pretty tricky, and you need to use a variety of types of tools to make things work for individuals who have a variety of disabilities. You and I today are going to focus a little bit more on the content provider’s responsibility.
So why accessibility? There are three reasons why accessibility. The first, and probably most noble reason, is because it’s the right thing to do. Accessibility is a civil right, so it’s every much a right of somebody who goes to your website, who downloads your mobile app, to access your content, as it is for that individual to walk into a place of business and ensure that they’re able to do whatever it is they need to do to interact with your business, be it going into a wide door of a business with a wheelchair and whatnot. Think of accessibility of digital content the same way as you would any other type of civil right. Everybody’s right to access publicly available information that is out there.
There’s a little bit more heat put on that as it relates to federal and state content, because there are taxpayer dollars in play. But accessibility is a civil right, so think of it as the right thing to do first. Secondly, think of it as good business. So a couple of months ago, I was actually at a mortgage company, onsite with a mortgage company, who was having some complaints being filed against them, because individuals were having trouble with their website. And so I walked them through the process of applying for a mortgage loan and showed them that, because of how things were coded, it was impossible for somebody like me using a screen reader to actually walk through and actually apply for a loan.
And guess what, folks. I have a house. There are a lot of people who are disabled have a house and who get loans like everybody else, mortgage loans, and go through that process and so forth. There are people who are visually impaired and in wheelchairs and whatnot who buy cars, who go shopping.
There are people like me who hate going to the store, and that has nothing to do with my visual impairment. That has probably everything to do with me being a guy and not liking to go to the store and wants to shop online, wants to buy things online, wants to get information online, wants to access my records online, medical records. All of that should be available to me.
If it’s not available to me, a couple of things can happen. The first thing that will always happen is, generally, people are going to be upset if you’re not able to access or interact with content. Then two things can happen. They can either leave your place of business online and go somewhere else, and at that point, you, perhaps, have lost a customer. But secondly, the third reason for accessibility can happen.
Legal consequences can happen, and folks can get sued and there are becoming more and more precedents on the books, lawsuits being one. Probably the first and foremost– and when you get the slide deck, there’s links to these specific lawsuits here– Target was probably the first and foremost, and they lost $6 million. They had to pay out $6 million and fix their website so that persons who are visually impaired could use it. Now Target has a beautiful site that works very well on your desktop and on your mobile phone. Before this lawsuit a number of years ago, that wasn’t the case, and they could have done the right thing, but it took a little bit of litigation in the tune of $6 million to happen before that occurred.
Secondly, probably another more private sector-related case, again, would be Winn-Dixie, last year, down in Florida, had similar type situations with their online site, and the plaintiff was sided with last year in court. And then, lastly, although Amazon has made some headway in some regard, there’s a class action suit filed against Amazon earlier this year, because they weren’t necessarily adhering to WCAG guidelines.
So there’s three specific links in this slide, when you get the slides with the recording that you should be able to access that will give you reasons why. The third reason, unfortunately, is the big reason that drives accessibility. It’s all about risk management, and so what we do at the Paciello Group is we help you manage that risk. It’s much easier to take the path of least resistance, and sometimes it might cost a little more, depending on where you’re at and what we might have to deconstruct and reconstruct. Maybe it does goes into court, paying court fees, possibly paying a settlement, and being forced to do it anyway.
So, again it’s, the right thing to do. It makes good business to do it, but thirdly, it’s risky business if you don’t do it. And you’ll have to answer some questions internally within your business, if it makes sense for you to take accessibility seriously or not. It’s like any type of rule. If you break the rule in certain ways, you might get caught. You might not get caught. I would never advocate breaking the rules, but at the same time, we can help you manage that risk so that while you’re trying to do the right thing, we can stave off any sort of litigation.
Let’s talk about how to become accessible now that we understand the what and the why, and we’ll talk a little bit about how. We’re going to review the components or accessibility coming up. Once we understand those components, we’ll review some tools and best practices for becoming accessible. And then I will end by encouraging you to align yourself with an accessibility partner.
Accessibility– excuse me– doesn’t necessarily happen just like that, and you may need some guidance to help you along the way. I do not expect everybody within the next 20 minutes that we have available and then time for question and answers. You’re not going to believe this webinar is being an accessibility expert at having equipped with everything that you need. But you will know enough to know that there are some things that you might need to tighten up, and you might be able to direct traffic as to what those things might be.
We’ll talk about the components to accessibility. So in a perfect world, it’s a good idea to build accessibility early on into your development process. And there is plenty out there that you can do as it relates to user stories and as it relates to wireframes and different things like that, where you can begin to build accessibility into the process earlier.
Think of it like building a house. If you took some shortcuts with your foundation, build, then, a brand new house, and then you’ve got this beautiful house built, but maybe there were some beams that were not aligned properly, or there were just some things that didn’t meet city code, what would happen? Chances are you’d have to knock a bunch of that house down, go in, fix things at the core foundation of what you’re doing. Heaven forbid you just might have to knock the whole thing down and start over. An unfortunately, there have been incidents where people have taken a path, a completely inaccessible path, and it has been tremendously painful to just start them over again.
We like to try to avoid that by getting in at the ground level. There’s a lot of things that you can do, a lot of things that you can do, a lot of research that you can do to make sure that you’re off to a good start. I’m a big fan of user stories. So for those of you who are early on in the process, and you’re beginning to scope out what it is, the project that you do, you typically will write user stories. The user will be able to do such and such. Think in terms of your disabled user, and begin to build user stories around what that might look like for them.
So if I’m going to log onto a site securely, maybe the accessible story needs to be, needs to be able to use the keyboard to tab to the appropriate edit fields, fill out the appropriate information, and select the Log On button with their keyboard. So you just need to think in terms of what it means for your accessible users as you begin to build out those stories, which will then give way to building wireframes and beginning to get into alpha and beta of certain types of code and so forth. We have a lot of individuals who are much smarter than I am who can help you along with the coding process.
So next thing that you need to do is you need to scope the content. So once you have begun to move towards a testing type situation, once we have done the preliminary guidance, you want to scope your content. What I mean by that is, what does your content involve? Does it involve videos? Does it involve PDFs? Does it involve HTML? Is there a native mobile app component to what you’re doing? And you need to appropriately scope everything that you have, and you need to collect the representative set of modules or a sampling of everything that you have as sort of your baseline for accessibility testing.
Nobody– at least not many people that I know of– test end to end anymore. There’s just not time to test every line of code that you do. So if you have sort of a representative set of things that you want to test, or you want us to test, or you want to test from a preliminary standpoint, you want to scope out everything that you have, you want to select, basically, all your different media types within your content, cross-platform, and you want to establish different pages, different screens, different things like that that encapsulate all those different media types and are a good reflection of what you want to test.
Then you want to move to an accessibility review. Accessibility reviews are best done by third parties. We do quite a lot of them, and what an accessibility review does is it gives you a snapshot, based on what is scoped, if you are conformant or not, conformant with those WCAG guidelines that we talked a little bit earlier. If you’re not, remediation guidance can be built into that. And once remediation guidance is offered, and you hopefully take that guidance and make the appropriate changes, it can be tested again. And that representative set of modules can be deemed conformant with accessibility guidelines.
And that is what a lot of folks look for, especially when you get into situations with lawsuits and things like that. You could get called out by a user, and your content could be completely accessible, and your user could actually be using really old technology and maybe not using their tools very well. So there are instances where individuals have been taken to task and have been completely in the right.
And so having an accessibility review and documented results is really important to protect yourself from a legal standpoint as well. But it also gives you the appropriate guidance that you need moving forward. And we also have some artifacts that can be provided based on an accessibility review. We provide an artifact called the Voluntary Product Accessibility Template, which is also another artifact that a lot of federal and state organizations look for from vendors. So that’s also very important.
We talked about remediate. We talked about certify or deeming something conformant. And then, also, we want to sustain. And so what you may have developed now may not necessarily be relevant next year, so we want to put a plan of sustaining your accessibility in place so that as you move forward, you’re using the appropriate best practices that ensure that you maintain that conformance. So the mobile app today will not be the mobile app in 2019. The website today is definitely going to have stuff added to it and changing and so forth, and so you want to sustain that accessibility.
A couple of free tools here for you to use, and, again, there are links in the actual slide deck. Probably the easiest accessibility tool you can ever have is a keyboard, just an external keyboard, preferably a USB, but Bluetooth, an external one, will work as well. One of the easiest things that any of you can do is go to a website, and tab through that website, and make sure that the focus is shifting, as you tab through a specific website, to all applicable elements within that website. And that can be a link. Make sure that the Tab key works. You don’t even need to have assistive technology loaded.
You can also do this with a Bluetooth keyboard on a mobile phone using your Tab key or your arrow keys as well. And so being able to tab around that website, enter into different types of areas on the website, you’ll be surprised. There might be some website that you’re tabbing through, and a big chunk of that website might not even be reachable by your Tab key, because it hasn’t been coded properly. And so just try it sometime, like whether you have a Mac, Windows, a Chromebook, or whatever. Open up a website, and just tab through it, and watch the focus change. And that is probably the simplest thing that you could do is use a keyboard.
One of the biggest violations out there is color contrast, and so we have a free color contrast analyzer that you can get from our website. And there’s a link there when you get the slide deck. You can go there, and you basically need to have a 4.5 to 1 color contrast ratio to fall into line with accessibility guideline for color contrasts. I don’t like to tell people they can skate 4 to 1 or whatever. It really should try to be 4.5 to 1. Color contrast is a bad one. A lot of people make that mistake, and so we have a way for you to change to different color palettes and test it and so forth using that tool.
We also have a tool called the Accessibility Viewer, which pretty much uses– provides information from an accessibility API. It’s a tool that you can use an inspect tool to pretty much ascertain how accessible the content is, the HTML content is to the document object model as it’s transferred to the screen reader, how the screen reader’s going to read your content. So there’s another tool that you can download and freely use. You’ll be able to link to that in your slides.
There are two types of testing you need to keep in mind. There’s manual testing, and there’s automated testing, and they’re both important. We have a few tools to help you with that. This is a tool called JAWS Inspect. Sorry about that. JAWS Inspect is a test tool that we have come out with to simulate the JAWS environment for an end user. It basically allows anybody, any of you on this webinar right now, if I were sitting next to you at your desk, I could have you running reports using JAWS Inspect within 10 to 15 minutes.
I’m gathering that some of you have probably never used a screen reader before, because you’re fully sighted. You don’t have to in JAWS Inspect. JAWS Inspect takes the stress off of using a screen reader to do manual testing and testing web content. It’ll basically run reports for you, shows you what the screen reader is saying, and so when there are problems, when the screen reader reads something that makes absolutely no sense, you’ll be able to see it, link it to the appropriate screenshot and the underlying code, select it, and dump it into a spreadsheet for trackability purposes.
My contact info I’ll be giving at the end of this. If there’s any of you who would like a JAWS Inspect demo after this webinar, and you want to get that scheduled, you can always feel free to contact me. JAWS Inspect is a one of a kind tool– there is no other tool like it– in that it builds a bridge between the sighted tester, the sighted developer, the sighted IT specialist, and the vision impaired user. Vision impaired user like me has spent quite a lot of time memorizing keystrokes. Use these tools very well. They’re user tools.
I’ve worked with individuals who I can teach to use a screen reader, but the results are going to be varied. And we don’t want to have any variance in our testing. This automates the entire process for you, and there’s no real variance. I could be working with Sofia, and if I taught Sofia how to use a screen reader in a few days, she’s going to have possibly very different results than me testing with a screen reader. This sort of brings it all together and sort of makes it very– it really makes it consistent, all the results that we would test for.
We also have an automated tool called ARC, our accessibility Resource Center. ARC is a spidering tool that sits in the Amazon cloud, can scan your code, let you know if your code violates accessibility type guidelines in a very automated way. I like to tell individuals that it’s important to run automated scans to do a lot of your heavy lifting and take care of a lot of your low-hanging problems. And in your manual tests, such as a JAWS Inspect type tool, would allow you to walk through your user stories and make sure that things are behaving like they’re supposed to.
ARC does the automated scan. It also helps you prioritize your accessibility program for your site or for your organization. We figure if we can help you prioritize fixing the top three things that are wrong, you’re going to take care of about 80% of your problems very quickly. And then we provide subsequent scans to track how you’re doing. We provide, basically, on call once a month an engineer to help you interpret results.
A lot of times, individuals will invest in these scanning tools. They have no idea what the results are saying. So we want to help you interpret that, and we want to make sure that you’re on the right track. And again, this is a risk management type situation. If you’ve got this running once a month, providing feedback– that goes a long way in a court of law when you’re legally called out. You can actually show what it is you’re doing and how you intend to remain accessible.
Let me go back one more. This also helps you publish out accessibility policies to your website, accessibility statements. You can actually create surveys for your disabled users to fill out, to give you suggestions on how to make things a little bit more usable. And there’s a lot built into ARC. We have a fully loaded knowledge base with all of our engineers, all of their brains kind of squished into one place, everything that they know as it relates to responsive web design, Android, and iOS development.
We also offer some eLearning modules to help you sustain that effort. A lot of times, it’s very expensive to have folks on site to conduct training. We do offer that. This is sort of a stopgap. We have a number of different courses here that are available– more on the way. There’s about 11 courses there. They’re all self-paced knowledge checks that can be built into an instance of ARC, or they can be published out to your own LMS if you have other eLearning efforts going on throughout your organization. We can publish those out to your LMS as well.
As I said, in conclusion, accessibility doesn’t happen overnight. It’s tough work. It’s tough work in the sense that if you have not been exposed to it before, there’s a lot to absorb. Once you begin to think in terms of the disabled user being a key market segment to who you’re trying to speak to and a customer that you’re trying to not just obtain, but retain, it only presents roughly a 3% level of effort in increase. So it’s not hard work, once you get a sense of what accessibility is. We, again, figure it’s about a 3% additional level of effort.
All accessibility is is good code. Occasionally, you’re going to get tricky, something tricky, depending on what you’re trying to do, but most of the time, if you just adhere to accessibility guidelines and best practices that are published and that are out there, accessibility is nothing more than good coding. And we want to help you manage that risk. We understand that this is a starting point for you to understand what accessibility is, why it’s important, and some of the ways that we get it done. But we wanted to take an opportunity just to introduce ourselves, Paciello, to the 3Play customer base and let you know who we are.
We’re very happy to be working with 3Play. They do a wonderful job as it relates to all things captioning, and we don’t. We don’t do captioning. We do accessibility reviews. We do VPATs. We provide guidance as it relates to ensuring that things across media types are accessible. And we produce testing tools, so we do not– we are not, ourselves at Paciello, we’re not in the closed captioning or any sort of captioning business. And so it’s great to have a partner with 3Play that we can turn to for that sort of assistance.
My contact information is here, and it will be part of the webinar slide deck, which you’ll be able to get. I’m fairly easy to get a hold of. There’s a bit of travel to what I do, but I’m very responsive to emails and phone calls and the like. And so if there are any– if there is anything that we covered, especially as it relates to JAWS Inspect, our Accessibility Resource Center, TVG Tutor, or just any desire to just take a walk-through of your continent, be it a desktop website or a mobile app or whatever, we would love to be able to help you with that.
We also do offer onsite training, where we can send developers in to help you folks learn how to code in an accessible sort of way. And we also offer situations where, if you need a person for one day a month, virtually or whatever, early on in your process, we can provide that sort of consultation and that sort of guidance as well. I have covered pretty much everything that I’m supposed to cover. And according to my clock, it is only 43 minutes in, so I’m going to step back and be ready to take some questions whenever Sofia’s ready.
SOFIA LEIVA: Thanks, Larry. So the first question that we have is, could you define what a VPAT is again, please?
LARRY LEWIS: Yep. So a Voluntary Product Accessibility Template is an artifact that a lot of organizations look for when they’re going to a vendor to determine whether or not what they’re investing in is accessible. So a federal agency, for whatever reason, needs to make sure that what they’re investing in has an element of accessibility built into it. So often, what they will do as part of their due diligence is they will go to a vendor site, and a vendor may have published that VPAT out there. And it will just– it’s supposed to say, what is– if the product is fully accessible, and if it’s not, what’s not accessible about it, and when might it be accessible.
The problem with VPATs is anybody sitting behind a desk can go through and create one and check things off and so forth. It doesn’t mean that it is. But when we provide a VPAT, we actually test everything. Like we test what it is we’re actually validating. And then we’ll base our validation, our findings on what we’ve actually tested for. So we legitimize the whole VPAT process and why it’s out there. VPATs can be tricky business, depending on if the vendor actually did what they were supposed to do for a VPAT.
And so VPATs can be very valuable to you if you’re trying to get into certain sectors, especially as it relates to federal business and those sorts of things. They’re going to look for a VPAT. They’re going to start to dig and ascertain. It doesn’t always work out this way, but in a perfect world, there’s not supposed to be– from a procurement standpoint, there’s not supposed to be procurement in inaccessible type of applications, unless there is a business need for it, and there is no other alternative out there. So a VPAT can be very valuable to, especially if you’re cleaning things up and making things accessible, it can be a way to get you into the government business.
SOFIA LEIVA: Thanks, Larry.
LARRY LEWIS: But also, it’s also becoming more prevalent in the private sector as well, so.
SOFIA LEIVA: Thanks, Larry. The next question we have is, you mentioned that publicly available information should be accessible. What about pay to play courses? Do they need to be accessible?
LARRY LEWIS: I would say if you would want the money of the disabled person, if it were like a– like if I’m getting this right, this would be something that’s fee-based. And I would say, if you want that person or if you think that there’s a risk that somebody who wants to take your course, and they try to pay for it, and they can’t take it, I would say, yeah, because I had a situation, actually, when I was actually trying to take some courseware published by a business school on an available eLearning site, and I wasn’t able to do it. I was able to get into the courses, but I wasn’t able to take them. And it became a problem.
So again, it’s all about risk management. I would say that if anyone that is– if the idea is anybody should be able to pay for that site and take it, your disabled market has money, and if it’s something that they’re interested in taking, and they want to pay for it, I would say yes.
SOFIA LEIVA: Thanks, Larry. The next question we have is, what is your opinion of the free NVDA screen reader as an alternate to the expensive and browser-locked JAWS?
LARRY LEWIS: Well, I’m not sure what browser-locked means, but I’ll put it to you this way. I think NVDA is a great free tool. I think JAWS is more expensive or quite a bit more expensive, because in employment studies and in educational studies where JAWS is used, there’s quite a lot of support that goes on day to day that a lot of people don’t necessarily know about.
I think NVDA is a great tool on the web and does a nice job, but when you’re in a school district, and your teacher is having an issue with their screen reader and their browser, and things might be locking up, and things happen, they’re typically not going to go to a forum to get help. They’re going to want some semblance of technical support, and that’s often what drives the expense of a product like JAWS.
As far as browser-locked, JAWS works with IE, Chrome, Firefox, and Edge. Not a lot of testing happening in Edge at this point, but it is really browser agnostic. It is expensive. It is fee-based because there’s a lot of support that goes into having a team of developers keep up with things to support all the different types of applications that it supports, primarily in corporate and federal sites.
SOFIA LEIVA: Great. Thank you. The next question we have is, how do I get buy-in from my organization to prioritize accessibility?
LARRY LEWIS: I would focus pretty heavily on the fact that it’s the law. It’s not necessarily just a nice thing to do. And is it worth it to them to risk not being accessible and the fallout of what could happen than to just spending less money to become accessible and avoiding the risk of possibly paying legal fees and being made to do it anyway? I mean, unfortunately, you have to lean pretty hard on risk, which I wish we didn’t have to do that as much.
SOFIA LEIVA: Thanks, Larry. The next question we have is, what are some of the most common pitfalls people make when they’re starting out with accessibility?
LARRY LEWIS: OK, so there’s a few of them. Probably the first and foremost that people make is they don’t label their graphics. And so if I’m moving through a website, and I read your graphic, the screen reader’s going to read to me the file name, typically, unless you put alt text into that graphic. You go into the properties of the graphic and actually put a small label of text just telling me what it is. So it could be– it could be, “Larry shaking Sofia’s hand.” It could be as simple as that. It could be, “Larry and Sofia smiling.”
It doesn’t have to– I tell people, think in terms of your alt text as a tweet– no more than 140 characters. You want to basically know what is being conveyed in that graphic, and if things get a little bit more intense, like it’s an alt text of an image of a graph or whatever, you can create long descriptions that can be read when the screen reader user presses the Enter key.
The second that happens, oftentimes, is form fields aren’t appropriately labeled. And so if I’m tabbing through a site, and I hear, “Edit,” I know it’s an edit field, but I don’t know what to put in that edit field. I don’t know if it’s a search field. I don’t know if it’s a login field for my first name. I don’t know exactly what that edit field is. The third thing would be, again, just along the whole labeling of the web elements, if I have an unlabeled one button, I don’t know if that’s a search button, a submit button, a login button.
So I would say graphics, labeling of web elements, and then probably making sure that headings, your H1 to your H6, your headings on a web page, those of us who are visually impaired use headings as quick ways to get around the web page. And so if you put like an H5 or an H6 at the top of your page, stylistically, I mean it might look OK to you. But I don’t want to hear any little thought at the top of my page. Typically, it doesn’t even have to be heading level 1, but as long as it’s somewhat sequential, like heading level 2, heading level 3, heading level 5, and you sort of maintain that chronological H tag order, headings are sort of like breadcrumbs, for those of us who are screen reader users, to jump around the screen pretty quickly.
The last one that I find quite a bit is error messages. If I make an error on a form or filling out something, and I press my Enter key, and I don’t direct the screen– I don’t program things to– the screen reader to go back to the focus of where the error message is, I could be sitting on my Submit button or whatever, pressing Enter, and nothing is speaking to me, and I don’t know what’s going on. Have I submitted my information? I mean there could be an error plain as day visually up higher, and if the focus doesn’t shift to that error, it could be really frustrating.
Those are four to get you started. I could prob– I could go on and on, but I would say those are the top four I would think– your alt text, your labeling of web elements, appropriate labeling, making sure your H tags are in order chronologically, and then error messages.
SOFIA LEIVA: Thanks, Larry. Those are some really great tips. The next question we have is, is there one tool that tests for compatibility with all major screen readers?
LARRY LEWIS: I mean, you know, JAWS and NVDA are very similar on the web for desktop. And VoiceOver and TalkBack are your mobile screen readers, and you’re going to get a lot of your low-hanging fruit taken care of. Now having said that, you still need to manually use a tablet or an iPhone or a Galaxy phone or a Samsung phone, I should say, and swipe through and do some things on the mobile front. But Inspect is going to show you– JAWS Inspect is going to show you, you know, [AUDIO OUT] what all screen readers are going to say.
And I say that, but I’m telling you, please do not test your mobile continent on a desktop computer. I said this until I was blue in the face. I used to manage a contract that tested all of the mobile apps for a federal organization. And I would be working with dev teams, having said this, and I would hear them on their desktop Macintoshes trying to test things they should be tested manually with their gestures on a mobile phone.
So I would say from a usability standpoint, JAWS Inspect will focus heavily on the JAWS screen reading experience. But I would also say, having used NVDA a fair amount for testing, they’re very similar how things are spoken, the way the information is reported to them.
SOFIA LEIVA: Thanks, Larry. I believe we have time for one more question. Have you found that accessibility features improve the experience for all viewers?
LARRY LEWIS: I think so, because if I have certain verbiage built in, it’s going to be helpful for somebody who can see. If I have [AUDIO OUT]. If I have a logical site, if I have a site that’s understandable, if it’s consistent across the entire domain, everybody is going to like that. Nobody’s going to be confused. So I think if you focus on consistency, and if it’s thoughtful, I also want to just say, in closing, I hate it when people dummy down a site for somebody who’s visually impaired at the expense of the visual user. You don’t have to do that.
Make your site look appealing for your predominantly sighted audience. Accessibility means accessing what everybody else accesses, not creating the separate but equal type site. So make it look good. Make it consistent. Make it logical. Make it operable. And I think if it’s created in a robust way, it’s going to improve everybody’s experience. I mean, accessibility should not be a ball and a chain. It’s a little bit more level of effort to make an experience better for all.
SOFIA LEIVA: Thank you, Larry, and thank you, everyone, for joining.