Hardware Engineer Pathway

What it means in practice

Design for the seated user from day one. Wheelchair-accessible reach is the controlling constraint for any kiosk or terminal. If a user in a wheelchair can reach every operable part, a standing user can too. The reverse is not true. The practical reach envelope: forward reach of 380 mm minimum at the lowest point, 1220 mm at the highest. Side reach goes slightly higher. Card slots, cash dispensers, receipt printers, emergency buttons — all of them need to fall inside that envelope. So do touchscreen interactive areas. A touchscreen mounted at standing eye level fails for seated users straight away. For controls, the test is one-handed operation with no tight grasping. A button you can press with one finger is fine. A latch that needs twisting and pulling at the same time is not. Door handles are a classic failure here — handles that require gripping and turning fail Clause 8.1.3 directly. Use lever handles instead. Knobs, switches and tactile controls should be distinguishable by touch alone. A bank of identical buttons with no tactile difference between them is a fail for blind users. Raised symbols, varied shapes, position-based discrimination — any of those work. Numeric keypads have to follow the standard layout (5 with a tactile dot, 1-3 across the top), based on ISO 9995-8. Users with low vision or blindness rely on that convention. For outdoor terminals, glare and weather turn into accessibility issues fast. A screen that's unreadable in direct sunlight is functionally inaccessible. Anti-glare coatings, recessed mounting, adjustable brightness — all of them help.

Common pitfalls

• ×Mounting the screen at standing eye level. Seated users can see it but can't reach the controls. The entire interaction model fails.
• ×Card slots above the reach envelope. Wheelchair users can't insert a card without asking for help.
• ×Identical-feeling buttons in a row. Blind users have no way to distinguish cancel from confirm without trial and error.

How to verify it

Test the device with an actual wheelchair user. If that's not possible at the prototype stage, test it with someone seated at wheelchair height (around 1200 mm eye level) with a 1200 mm maximum reach. Every operable part should be reachable. Every screen should be readable from the seated angle. For tactile testing, try to use the device blindfolded. Can you find every control? Can you tell them apart? Can you complete a full transaction without sight? If not, the tactile design needs work. The Hardware Checklist on this site walks through Chapter 8 clause by clause. Use it for design reviews and for final testing.

What it means in practice

If your device has a screen and gives visual feedback, plan for audio output from the start. For an ATM, that's a headphone jack with private audio output that reads the screen, the prompts, and the transaction confirmation aloud. Get the headphone jack into the BOM at design time. Retrofitting it later is expensive and usually impractical. The audio output should be adjustable in volume, suppressible so sighted users aren't bothered by speech they don't need, and actually comprehensible. Don't use proprietary speech synthesis — use a standard TTS engine that can handle currency, names, and addresses without mangling them. Test it with users who actually depend on it. For biometrics, always provide an alternative. Fingerprint, face, voice, iris — every one of these fails for some users. Burns, scars, low vision, language differences, you name it. The alternative needs to be equivalent in security and convenience. A PIN with an accessible keypad. A contactless card. A magnetic stripe with audio guidance. Don't make the alternative the slow lane — that's discriminatory by design. The Biometric Matrix on this site evaluates biometric authentication against accessibility, AI Act, and GDPR requirements at the same time. Worth running for any new biometric deployment.

Common pitfalls

• ×Adding 'voice mode' as a software-only feature on a device that has no audio output hardware. Without a speaker or headphone jack, the feature does literally nothing.
• ×Biometric authentication as the only login option. A user who can't enrol the biometric (or whose enrollment expired) has no way in.
• ×Speech output running on a low-quality synthesiser nobody tested properly. Currency amounts read as 'one zero zero' instead of 'one hundred' makes the device unusable for the people who need it most.

How to verify it

For audio output, test the full flow with eyes closed and headphones on. Can you complete a transaction? Can you correct a mistake? Can you cancel out of one? If the audio skips any of those steps, the implementation is incomplete. For biometric alternatives, deliberately bypass the biometric and try the alternative path. It should work without delay, without extra friction, and without alerting other users in the queue that you're using it.

What it means in practice

Connectivity is your friend. A device that pairs with a phone over Bluetooth can offload most of the accessibility work to the phone's built-in screen reader and assistive features. Apple's MFi Hearing Aids program and Android's Audio Streaming for Hearing Aids let hearing aid users receive device audio directly. Switch Control on iOS and iPadOS works with any device that exposes a standard HID interface. Build for these protocols rather than against them. A smart speaker with a paired phone app can use VoiceOver or TalkBack on the phone for the setup flow, which removes the need to design a fully blind-accessible setup experience on the speaker itself. A printer with AirPrint inherits accessibility from the operating system for free. For industrial or specialised hardware where standard connectivity isn't an option, document what assistive technology the device supports and how to connect it. The AT Interoperability Checklist on this site covers the testing methodology for those scenarios. Don't break standard interfaces with proprietary modifications. A USB-C port that only accepts the manufacturer's cables, a Bluetooth profile that only talks to one app, a touchscreen that doesn't expose the accessibility tree — every one of those breaks interoperability and makes the hardware less accessible than it needs to be.

Common pitfalls

• ×Proprietary connectors and profiles that lock out third-party assistive technology.
• ×Bluetooth pairing that requires a sighted setup step — entering a PIN shown on a screen — with no audio alternative.
• ×Assuming that connecting via a standard interface is enough. The accessibility tree on the connected device also has to be exposed correctly, or you've achieved nothing.

How to verify it

Test the device with a real assistive technology setup. Pair it with an iPhone running VoiceOver and try to set it up and operate it. Connect it to a switch controller. Connect it to a refreshable braille display. Each test surfaces a different gap. The AT Interoperability Checklist on this site gives you a structured test plan for those scenarios. Run it during development, not after launch.

What it means in practice

Build the technical file as you build the product. Trying to assemble it after the fact, from memory and old design documents, is the standard way this goes wrong. The technical file should include a description of the product, the design and manufacturing drawings, the bill of materials, the test reports against EN 301 549 clause by clause, the conformity assessment itself, and the declaration of conformity. The Module A conformity assessment is a self-declaration, but it has to be backed by real evidence. Run the EN 301 549 Chapter 8 test plan. Document the results. Where you've used the harmonised standard in full, you can claim presumption of conformity — the regulator has to accept your conformance unless they can show otherwise. Where you've deviated, document the alternative method and explain how it produces an equivalent outcome. The CE marking goes on the product itself wherever it's practical, at the size and visibility specified in Annex VI of the wider New Legislative Framework. For very small products it can go on the packaging instead. Affixing the CE marking without a valid conformity assessment behind it is a regulatory offence in its own right. The Conformity Generator on this site produces an EU Declaration of Conformity in the standard format that you can adapt to your product. The Compliance Programme Template covers the broader documentation lifecycle around it.

Common pitfalls

• ×Assembling the technical file at the end of the project from incomplete records. Critical evidence is missing and the whole conformity claim becomes fragile.
• ×Affixing CE marking without actually running the conformity assessment. Direct breach of Article 16, and discoverable in any audit.
• ×Treating the conformity assessment as a one-time event. Product changes invalidate the assessment. A refreshed product needs a refreshed assessment.

How to verify it

For each product line: does the technical file exist, is it complete, is it stored somewhere you'll still be able to find it in five years? Is the EU Declaration of Conformity current? Is the CE marking present and correctly applied? For active production, when was the last conformity assessment? If the product has changed since, the assessment is stale and needs redoing.