Sharing the split screen with me is a document with the heading ADA Web Compliance Checklist for Restaurants. So some considerations you want to keep in mind.
First subheading, menus. It is extremely important that you make sure your menu is accessible. And what I have seen many times from smaller restaurants is that menus are completely inaccessible. The restaurant will rely upon customers’ photos of the menu or they will rely upon photos of the in-restaurant menu.
So it could be a chalkboard with everything listed and it’s a photo of that. If the information is not available programmatically, it is not accessible and that’s just to start with. Also, some restaurants have PDFs as their menu. But PDFs need to be made accessible as well. And so those PDFs can be inaccessible.
Again, if you are taking photos of menus or doing anything of that sort, then it’s going to be an accessibility issue. You need to make sure everything is available programmatically and it is navigable. So starting with menus, that’s one point where I would focus in on.
Also, any third-party integration. So any apps that you are using so that your restaurant can function, I would pay attention to. So reservation apps such as OpenTable or Resy and there are other apps. I don’t know the accessibility of either of these apps. The point is that if you have integrated into your operations a reservation app, you need to make sure that that app is accessible.
Also, online order apps. So I have listed here under bullets, PopMenu, Uber Eats, DoorDash, GrubHub, etc. Whoever you are relying upon to fulfill customer orders or reservations or any type of functionality, it could be even payment processing. You need to make sure that that third-party integration is accessible.
Because if it is not, then you are ultimately very likely to be responsible for any accessibility issues that result from customers attempting to access your restaurant or your website or the website functionality, etc.
So when dealing with these third-party integrations, ask them for a VPAT. So it’s a Voluntary Product Accessibility Template. That is the term most commonly used in the marketplace. The technically correct term is an ACR. So you may ask them for a VPAT or an ACR. An ACR is basically a filled out VPAT. The VPAT is the template. The ACR is the filled out template. An ACR stands for Accessibility Conformance Report.
You can also ask for a statement of conformance. You could also even ask for their audit if they’ve ever had their digital asset. So it could be their app audited. Ask them for a copy of that audit. And what that will help you do is it will help you assess their accessibility.
Now it’s not that these third-party integrations have to be completely accessible. If they have some accessibility issues, what I have found is that many third-party apps still have some accessibility issues. What you are looking for is to make sure that those accessibility issues are not so significant that they could create a barrier to access.
So for example, if an app does not meet color contrast thresholds, and let’s say their color contrast for a certain font is 4.2 to 1 and it’s a normal size font, that wouldn’t technically meet the Web Content Accessibility Guidelines, which are the technical standards that we commonly look to as a reference for accessibility. But that app could very well still be accessible.
So it’s not that full conformance is a must-have, but what we must have is an excellent level of accessibility and ensuring that there are no barriers to access.
What I would also pay attention to are the primary flows of your website or of your operations. So what would a customer typically do if they were coming to your restaurant? Well, they would browse the menu, they would add items to cart, and they would check out. So I would make sure that that primary flow and any other that is typical of your customer, I would make absolutely sure to prioritize and make sure that those flows are accessible.
Now, this is all beyond the two best practices for accessibility. These are specifics to the restaurant industry. Of course, you want to make sure that your digital assets are fully WCAG 2.1 AA conformant, but full conformance will take you some time to get through, so you do need to prioritize certain accessibility issues above others because certain accessibility issues are more likely to create barriers to access and certain accessibility issues are more likely to lead to litigation.
There are about 15 accessibility issues that are the most commonly claimed issues in litigation, and I say about because some of the issues aren’t even technically accessibility issues under the Web Content Accessibility Guidelines, but that’s besides the point. Just think there are 15 accessibility issues that commonly find their way into litigation, so you want to make sure to prioritize those, and the good news is that as you are prioritizing those, you will genuinely make your website more accessible, and you will eliminate many of the key areas that present barriers to access, and so then you can work towards full conformance, but what you want to do is prioritize those issues that are most commonly claimed in litigation so that you can reduce your risk of litigation as you are working on accessibility.
And then continuing on the document, I have also an accessibility statement is paramount, so you need to make sure that you have an accessibility statement, and that it at least contains two things. One, a statement of commitment to accessibility, and then two, at least one method for feedback and support specific to accessibility.
So these are the best practices for ADA web compliance as it applies to restaurants. Of course, there is more here, but these are some of the most important considerations for restaurants, both large and small, and so with this checklist, it leads to my ADA Compliance Course. My ADA Compliance Course is going to train your web team on how to find and fix the most commonly claimed issues in litigation. It is extremely helpful, it gets right to the point, and then there is also the option for support.
