Accessibility Standards for the Networks You Deploy

If you build and run digital signage for other organizations, accessibility is not a feature you evaluate once. It is a question your clients' procurement teams will put to you on every hospital, campus, and public sector bid, and increasingly it is scored. This page is written so that you can answer it accurately, cite the right standard, attach the right document, and be clear about which parts of conformance are ours, which are yours, and which belong to your client.

Looking for how firmchannel.com itself conforms? That is on our website accessibility statement.

The Three Questions Every Procurement Asks

Accessibility sections in RFPs vary in wording and almost never in substance. Underneath, there are three questions.

Is the hardware accessible?

Can a person in a wheelchair reach and operate the kiosk? Can someone with limited dexterity use its controls? Is the screen at a height and angle a seated person can read? This is a built environment question, governed in the United States by the ADA Standards and in Canada by CSA/ASC B651.2 and AODA.

Is the software accessible?

Can a person who cannot see the screen, or cannot read it at its default size, still get where they are going? This is governed by WCAG and by the regulations that adopt it, which since 2024 include two US federal rules that name kiosk based services directly.

Can you prove it?

Evaluators want a document, not a paragraph. A conformance statement for the specific hardware configuration, a description of the software's accessibility features mapped to the standard the RFP cites, and, increasingly, a VPAT. The proposal that attaches these scores; the one that promises them later does not.

Who Is Accountable for What

In a partner deployment there are three parties, and conformance is split among them. Proposals go wrong when a partner claims the whole of it, or assumes Corum carries the whole of it. Neither is true.

How accessibility responsibility divides between Corum, the partner, and the client in a partner deployment.
Requirement Corum Partner Client
Kiosk enclosure design: reach range, control placement, screen angleOwns
Kiosk installation: mounting height, floor clearance, approach, placement of signage on the latch sideOwns
Wayfinding application conformance (WCAG 2.2 AA)Owns
Platform controls for contrast, type size, multilingual contentOwns
Content authored on the platform: contrast, legibility, alternatives for image only informationAdvisesOwns
Accessible route data: which paths and transitions are marked accessibleConfiguresOwns, as the source of truth for the building
Enabling visitor facing accessibility controls on each mapOwns at deploymentMaintains
Alternative procedure where a kiosk is unavailable (required by HHS 504)Owns
Conformance documentation for the proposalSuppliesAssembles

The row that surprises most partners is installation. A kiosk enclosure can be designed to every reach range requirement and fail on site because it was mounted two inches high or set where a wheelchair cannot approach it squarely. That is an installer's responsibility, and in a partner deployment the installer is you. Our installation guidance covers it; the proposal should say that you follow it.

Who is accountable for what in a partner deployment: Corum, the partner, and the client Three columns connected left to right by arrows. Corum owns the kiosk enclosure design, the wayfinding application's WCAG 2.2 AA conformance, and the platform's accessibility controls, and hands the partner a hardware conformance statement and an application feature description. The partner owns installation, including mounting height, approach and clearance, enables the visitor-facing accessibility controls on each map, configures accessible route data with the client, and assembles the proposal, handing the client an installed and configured deployment plus the attached documentation. The client owns the content it authors on the platform, the accuracy of which routes are marked accessible, and the alternative procedure required where a kiosk is unavailable. A footer line says that proposals fail when one party claims all three columns. Who is accountable for what Conformance is split across three parties. Each hands something to the next. Nobody owns all of it. CORUM Builds it Kiosk enclosure design: reach range, controls, screen angle Wayfinding application: conforms to WCAG 2.2 Level AA Platform controls: contrast, type size, languages HANDS OVER Hardware conformance statement Application feature description PARTNER Installs and configures it Installation: mounting height, approach, clearance Enables visitor controls: speech, text size, step-free, per map Assembles the proposal: cites the right standard, attaches docs HANDS OVER Installed, configured deployment Attached documentation CLIENT Runs it Content it authors: contrast, legibility, alternatives Accessible route data: which paths are truly step-free Alternative procedure: when a kiosk is unavailable (HHS 504) KEEPS CURRENT Maps, closures, and content Controls left enabled Proposals fail when one party claims all three columns. A partner cannot promise conformance for content the client will write. Corum cannot promise a kiosk was mounted at the right height. State the split; evaluators score precision over breadth.
What each party hands to the next, and what each one owns.

Why a Kiosk Has to Carry Its Own Accessibility

One idea explains most of the software requirements, and it is worth being able to state it in a proposal.

A kiosk is what the standards call a closed functionality device. A visitor cannot attach their own screen reader, cannot launch the operating system's magnifier, and cannot change any setting, because the device is locked to one application with no keyboard. Every assistive tool a person uses at home is unavailable at the exact moment they are standing in your client's lobby.

Where ICT has closed functionality, that closed functionality shall be operable without requiring the user to attach, connect or install assistive technology.

EN 301 549, clause 5.1

So the application has to supply the equivalents itself, and the visitor has to be able to reach them without asking staff:

  1. Speech output, standing in for the screen reader that cannot be attached.
  2. A text size control the visitor operates, standing in for the magnifier that cannot be launched.
  3. Step free routing the visitor switches on, because a route that assumes stairs is not a route for everyone.

An evaluator who knows this area will ask whether these are visitor invoked or administrator settings. The difference matters. A text size an installer set once does nothing for the person at the screen.

Why a kiosk must supply its own accessibility features Two columns. On the left, what a visitor can do at a personal device: attach a screen reader, launch the operating system magnifier, change system settings, and use a keyboard. On the right, the same four options at a locked kiosk, all unavailable, because the device is closed to assistive technology. Below, the three capabilities the product must therefore build in itself: speech output in place of a screen reader, a user-controlled text size toggle in place of a magnifier, and step-free routing in place of assuming every visitor can use stairs. A closing line notes that the control must belong to the visitor, since an administrator setting does nothing for the person standing at the screen. Why a kiosk has to supply its own accessibility features On a personal device The visitor brings their own tools ✓Attach a screen reader ✓Launch the system magnifier ✓Change system settings ✓Use a keyboard At a locked kiosk Closed functionality: none of it is available ✕No connection for assistive tech ✕No access to the operating system ✕No settings the visitor can reach ✕No keyboard So the product has to provide the equivalent itself Speech output Directions read aloud, because a screen reader cannot be attached Text size the visitor sets Enlarge the interface on the spot, because a magnifier cannot be launched Step-free routing A route to elevators and ramps, because stairs are not a route for every visitor The control has to belong to the visitor. A text size an administrator set at installation does nothing for the person standing at the screen.
Why a kiosk must supply its own accessibility features.

The Rules Your Clients Are Under

Which standards apply depends on who your client is, not on where the kiosk is made. This table is organized the way your proposals are: by client type.

Accessibility standards by client type, what each requires, and its current status.
If your client is… Standard What it requires Status
A US healthcare provider receiving HHS funding (most hospitals, many clinics) HHS Section 504 Final Rule Websites, mobile apps and kiosk based services, explicitly including wayfinding, at WCAG 2.1 AA. An alternative procedure where a kiosk is not accessible Published May 9, 2024. Deadlines May 11, 2027 (15+ employees), May 10, 2028 (smaller)
A US state or local government body, including public universities, school districts, and public hospitals DOJ Title II Final Rule Web content and mobile apps at WCAG 2.1 AA Published April 24, 2024. Deadlines April 26, 2027 (large), April 26, 2028 (smaller and special districts)
Any US organization, for the physical kiosk and its signage ADA Standards §216, §703, §308 Tactile characters 48 to 60 in above floor, raised min 1/32 in, non glare, contrast; reach ranges for operable parts In force
Any US organization with ATMs or fare machines ADA Standards §707 Speech output, tactile keys, privacy In force for ATMs and fare machines only. Does not cover information kiosks. Access Board has signalled intent to extend to self service kiosks
A US federal agency or contractor Section 508 (2017 refresh) WCAG conformance for ICT In force
An Ontario organization AODA, O. Reg. 191/11 Signage contrast, tactile requirements, braille, tactile walking surface indicators; accessible public websites for larger organizations Full compliance since January 1, 2025. Penalties to $100,000/day individuals, $200,000/day corporations
Any Canadian organization, for the kiosk hardware CSA/ASC B651.2 Design, manufacture, site preparation and installation of self service interactive devices 2025 edition current. 2007 superseded by 2022, then by 2025
A Canadian public space, transportation facility, or workplace CAN-ASC-2.4 Wayfinding and Signage Lighting and contrast, wayfinding paths and tactile indicators, signage including audible and electronic signage, maps Draft, posted January 2026. Publication expected summer 2027
A European public body EN 301 549 (Mandate M/376) Clause 5.1 governs closed functionality In force, V3.2.1. V4.1.0 in draft

Do not cite Section 707 for an information kiosk

Section 707 is the ADA's speech output requirement and it is regularly cited in proposals as applying to kiosks generally. It applies to ATMs and fare machines. Citing it for a wayfinding kiosk tells an informed evaluator the proposal was assembled from a template. The accurate statement is that the Access Board has signalled intent to extend those requirements to self service kiosks, and that the hardware and application you are proposing are specified as though they already apply.

Check the edition of CSA/ASC B651.2 in the RFP

The Canadian kiosk standard has been revised twice in three years. Client RFPs still cite the 2007 edition because that is what their last consultant wrote. If an RFP cites B651.2-07, ask the evaluator which edition they intend to apply, in writing, before you answer. It shows you know the standard, and it protects you from being scored against one edition while having answered another.

Why the rules say WCAG 2.1 and the application says WCAG 2.2

The two US federal rules cite WCAG 2.1 Level AA because that was the current W3C Recommendation when they were drafted. WCAG 2.2 became the Recommendation in October 2023. It carries forward the 2.1 success criteria and adds nine more, several of them directly relevant to touch kiosks, such as minimum target size and visible focus. (The one 2.1 criterion that 2.2 retires, 4.1.1 Parsing, is one that W3C now treats as always satisfied under 2.1 as well.)

So a product that conforms to WCAG 2.2 AA satisfies what the regulations ask for and goes past it. When an RFP cites 2.1, answer with 2.2 and say so: "conforms to WCAG 2.2 Level AA, which incorporates and exceeds the WCAG 2.1 Level AA standard cited." It is accurate, it is one sentence, and it tells the evaluator you know the difference.

Dates Inside a Deployment's Service Life

A kiosk your client buys this year will still be in service when every date on this timeline has passed. Proposals that acknowledge that read as competent; proposals that ignore it read as hardware sales.

Accessibility compliance deadlines affecting kiosks and digital wayfinding, 2025 to 2028 A timeline from 2025 to 2028. AODA reached full compliance on January 1, 2025, already in force. CAN-ASC-2.4, the Canadian wayfinding and signage standard, is expected to publish in summer 2027. DOJ Title II requires WCAG 2.1 Level AA for large public entities by April 26, 2027 and for smaller entities and special districts by April 26, 2028. HHS Section 504 requires WCAG 2.1 Level AA for websites, mobile apps and kiosk-based services, explicitly including wayfinding kiosks, by May 11, 2027 for recipients with fifteen or more employees and May 10, 2028 for smaller ones. A closing note observes that a kiosk specified today will still be in service when these dates arrive. Deadlines landing inside the service life of a kiosk bought today US federal rules in blue, Canadian standards in orange. 2025 2026 2027 2028 AODA, full compliance January 1, 2025. Already in force. Penalties to $200,000 per day for corporations. CAN-ASC-2.4, Wayfinding and Signage Publication expected summer 2027. Covers audible and electronic signage. draft posted Jan 2026 DOJ Title II State and local government, public universities and hospitals Apr 26, 2027 large entities Apr 26, 2028 smaller entities HHS Section 504 Recipients of HHS funding, including most hospitals. Names wayfinding kiosks. May 11, 2027 15+ employees May 10, 2028 smaller Both US rules require WCAG 2.1 Level AA, and both reach kiosk-based services. A kiosk specified this year will still be in service when every date on this timeline has passed.
Accessibility compliance deadlines affecting kiosks and digital wayfinding, 2025 to 2028.

What the Platform and Application Provide

Kiosk hardware

Our kiosk range has been assessed by CSA Group against CSA/ASC B651.2-2025, the current edition of the Canadian standard for accessible self service interactive devices, and is designed to the reach range requirements of ADA Standards Section 308. Enclosures are available in configurations addressing reach range, screen height and angle, approach clearance, and operable part placement, and are deployed in healthcare, government, transit, and education environments where conformance is scored. Installation guidance for mounting height and approach is provided to partners and should be cited in proposals as followed.

See the kiosk range

Wayfinding application

The wayfinding application conforms to WCAG 2.2 Level AA. It is built around the closed functionality principle, with three controls operated by the visitor at the kiosk and no staff assistance required: spoken turn by turn directions through the kiosk speakers, a text size toggle, and step free routing that avoids stairs and escalators and directs visitors to elevators and ramps using only transitions the venue has marked accessible.

Underneath: four routing profiles (standard, wheelchair, no stairs, stairs only), accessibility flags on every path and every transition so the venue's own data decides, accessible routes precomputed into the offline package so the option works with the network down, sixteen languages with a visitor facing switcher and right to left rendering, and configurable text size, label size, and contrast per location.

See interactive wayfinding

Signage platform and content

The platform provides contrast control, type size control, multilingual content, and scheduled content. Content conformance is shared: the platform supplies the controls, and the content your client's team creates has to use them. Where you author content on the client's behalf, that responsibility moves to you, and it should be priced and scoped that way.

Answering the Accessibility Section of an RFP

A repeatable approach, in the order an evaluator will read it.

  1. Identify the client type and the standard it triggers, from the table above. Cite that standard by name and section. Do not cite everything.
  2. Separate hardware from software in your answer. Evaluators score them separately and a merged paragraph loses points on both.
  3. State who owns what, using the responsibility matrix. Claiming full conformance for content your client will author is a claim you cannot keep.
  4. State the WCAG level of the application as a fact, not a commitment: WCAG 2.2 Level AA.
  5. Describe the three visitor invoked controls, and say that they are visitor invoked. That phrase is what an informed evaluator is looking for.
  6. Commit to installation conformance as your own deliverable, referencing our installation guidance and the reach range requirements of the standard the RFP cites.
  7. Attach the documents rather than offering them on request.

What to attach

  • Hardware conformance statement for the configuration proposed, citing the CSA Group assessment against CSA/ASC B651.2-2025
  • Description of application accessibility features, mapped to the cited standard, including WCAG 2.2 Level AA conformance
  • Where the RFP supplies an accessibility matrix, the completed matrix. Request it from your partner contact; we do not publish a VPAT, and the statement and feature description are provided in its place
  • Your own installation conformance commitment

Request the hardware statement and the application feature description from your partner contact, and tell us which standard and edition the RFP cites so the documents match it.

Partner Questions

What should I attach to an RFP that asks about accessibility?

A hardware conformance statement for the specific kiosk configuration you are proposing, a description of the wayfinding application's accessibility features mapped to the standard the RFP cites, and your own installation conformance commitment. Attach them; do not offer them on request. Ask us for the first two, and tell us which standard and edition the RFP names so the documents match.

Who is responsible if a kiosk is installed at the wrong height?

The installer. Enclosure design covers reach range and control placement; mounting height, floor clearance, and approach are decided on site. In a partner deployment that is your responsibility, our installation guidance covers it, and your proposal should commit to following it.

Can I claim WCAG conformance for the whole deployment?

For the wayfinding application, yes: it conforms to WCAG 2.2 Level AA. For content your client authors on the platform, no, and you should not, because you do not control it. State the split. Evaluators respect a precise claim more than a broad one.

Does Section 707 apply to the kiosks I am proposing?

Not today. Section 707 covers ATMs and fare machines. The US Access Board has signalled intent to extend its requirements to self service kiosks by rulemaking, so specify as though it will apply within the equipment's life, and say so in the proposal rather than citing 707 directly.

The RFP cites CSA B651.2-07. What do I do?

Ask the evaluator, in writing, which edition they intend to apply. The 2007 edition has been superseded twice, most recently by the 2025 edition. Answering against the wrong edition is a scoring risk, and asking demonstrates you know the standard.

My client is a US hospital. Which rule matters most?

The HHS Section 504 Final Rule. It applies to recipients of HHS funding, requires WCAG 2.1 Level AA for kiosk based services including wayfinding, and requires an alternative procedure where a kiosk is not accessible. Compliance dates are May 11, 2027 for larger recipients and May 10, 2028 for smaller ones.

Are the accessibility controls on by default?

The visitor facing controls are optional per map. Enable them on every deployment where conformance is a requirement, and record that you did so in your handover documentation. A control the visitor cannot reach does not satisfy a closed functionality requirement.

Do you provide a VPAT?

No, and we do not plan to publish one. For any procurement we provide a written statement of conformance for the specific hardware configuration proposed, citing the CSA Group assessment against CSA/ASC B651.2-2025, together with a description of the wayfinding application's accessibility features mapped to the standard the RFP cites, including its WCAG 2.2 Level AA conformance. Where the RFP supplies its own accessibility matrix, we complete it. Ask your partner contact and tell us which standard and edition the RFP names.

Request conformance documentation

Tell us which standard and edition the RFP cites, and the kiosk configuration you are proposing, and we will send the hardware conformance statement and the application feature description to match.

Request conformance documentation