Restaurants, cafés and hospitality
Website accessibility for Manitoba restaurants, cafés, hotels and caterers: menus, reservations, online ordering and Man. Reg. 47/2022.
Most people look at a restaurant's website before they visit. They want the menu, the hours, the address and a way to reserve a table or order for pickup. Hotel guests want room details, rates and a booking form. Catering clients want a package list and a quote. If the menu is a photo of a printed page, or the reservation button cannot be reached with a keyboard, a guest who uses a screen reader or magnification may simply choose somewhere else.
About 27% of Canadians aged 15 and over reported one or more disabilities in 2022 (Statistics Canada, Canadian Survey on Disability 2022). In hospitality, the guest with a disability is often the one choosing where the whole group goes. Since May 1, 2025, organizations with one or more employees in Manitoba have been covered by Man. Reg. 47/2022, which requires web content to meet WCAG 2.1 Level AA (s. 7(1) (opens in a new tab)).
Where websites in this sector usually fail
These are patterns we commonly see across hospitality websites. They describe typical issues, not any particular business.
| Criterion | Issue | Where it appears |
|---|---|---|
| 1.1.1 (opens in a new tab) | Menus published as images or scanned PDFs with no text equivalent | Menu pages, daily specials, catering packages |
| 1.4.3 (opens in a new tab) | Text over food or room photography with insufficient contrast | Home page banners, promotional sections |
| 2.2.2 (opens in a new tab) | Auto-playing carousels or background video with no pause control | Home pages, room galleries |
| 2.1.1 (opens in a new tab) | Item customization, quantity steppers or date pickers that need a mouse | Online ordering, reservation and room booking |
| 4.1.2 (opens in a new tab) | Modal pop-ups and "add to order" buttons without accessible names or states | Ordering menus, cart drawers |
| 2.4.3 (opens in a new tab) | Focus that does not move into a pop-up, or gets lost behind it | Reservation dialogs, newsletter and promotion pop-ups |
| 1.3.1 (opens in a new tab) | Dietary and allergen icons with no text meaning | Menu listings |
| 1.4.10 (opens in a new tab) | Menu tables and embedded maps that force sideways scrolling at 320 CSS px | Menu, location and contact pages |
The journeys we test first
- Reading the full menu, including prices, allergens and dietary notes
- Reserving a table or booking a room, including choosing a date and party size
- Ordering for pickup or delivery, from item selection through payment
- Finding hours, location, parking and entrance accessibility information
- Requesting a catering or event quote
- Buying a gift card
Each journey is tested with keyboard only, NVDA on Windows, VoiceOver on macOS and iOS, text resized to 200% and content reflowed at 320 CSS px, alongside automated scans. Our method page explains the process.
A menu in an image or a scanned PDF is one of the most common barriers in this sector, and one of the simplest to fix. An HTML menu page usually serves screen reader users, mobile visitors and search engines better than a picture of the printed menu, and it can be styled to look the same.
Beyond the website
Accessible formats and communication supports (s. 5 (opens in a new tab))
Guests should know they can ask for information in a format that works for them. For a restaurant, that might mean a large-print menu at the host stand, a staff member who will read the menu aloud, or an accessible version sent by email. For a hotel, it might mean accessible versions of the guest directory or event information. A short notice on the website and at the front desk lets guests know these options exist.
Feedback process (s. 9 (opens in a new tab))
Guests need an accessible way to report barriers, whether on the website or in person. A listed email address, a phone number and a simple web form usually cover this.
Training (s. 4 (opens in a new tab))
Hosts, servers and front desk staff communicate publicly on your behalf. So does whoever posts menus and specials online, and whoever chooses ordering or reservation software. Each of them falls within the training requirement, which applies as soon as reasonably practicable. Large employers must also document a training policy (s. 4(4) (opens in a new tab)).
What an engagement looks like
Hospitality websites are often built on WordPress, Shopify or a hosted site builder, with embedded tools for reservations, room booking or online ordering. We plan around that mix.
- Audit. We test the journeys above against all 50 WCAG 2.1 AA success criteria and record each issue with its location.
- Fixed quote. You receive a written, fixed quote before any work begins.
- Remediation that preserves your design. We rebuild image menus as text, correct contrast, labels and focus handling, and add pause controls, keeping your look and brand intact. For embedded reservation or ordering tools you do not directly control, we document the issues, review the exceptions in s. 7(2) (opens in a new tab), and help you request fixes from the provider or offer an alternative such as phone ordering.
- Verification. Every repair is retested with assistive technology.
- Compliance pack. You receive notice and feedback wording, documentation and training material for your staff.
We do not use overlay widgets. If anything we repaired is later found not to meet WCAG 2.1 AA, we correct it at no charge. See our services.
To find out where your website stands before the next menu change, contact us, call (431) 816-6210 or email hello@prairieaccessibility.ca.
Last reviewed October 2026. General information, not legal advice.
Next step
Find out where your website stands.
Book a 20-minute consultation. We review your website with you, explain what applies to your organization, and follow up with a fixed written quote.