Hardware accessibility testing services for Section 508 ICT
Section 508 reaches the device, not only the software on it. Our hardware accessibility testing services cover both halves of what a federal buyer asks for: hands-on evaluation against Chapter 4 of the Revised 508 Standards, with the measurements recorded and every finding tied to the provision it fails, and the conformance report that has to hold up before an award.
Hardware accessibility services for ICT products
Two services, usually bought together: the evaluation that establishes where your device actually stands, and the conformance report your buyers ask to see. We scope them as one engagement so the evidence and the paperwork describe the same product.
Hardware accessibility testing services
We evaluate your device by hand against the hardware requirements in Chapter 4 of the Revised Section 508 Standards, with measurements recorded and every finding tied to the provision it fails. What you get back is specific enough for an engineer to act on.
VPAT and ACR for hardware
When a buyer asks for accessibility documentation, they want a conformance report backed by evaluation. We complete the VPAT in the correct edition and write the ACR so it states what was tested, on which version, and where the limits are.
When hardware accessibility testing is required
Section 508 applies to all ICT that is developed, procured, maintained, or used in a U.S. federal agency environment, and ICT is the federal term for the whole estate of hardware and software, not software alone. Testing becomes necessary when you sell devices into government or public-sector environments, respond to an RFP, or support a buyer who has to document ICT accessibility before an award.
The pressure usually arrives from the buyer rather than from a regulator, and it arrives late — inside a procurement window, with a deadline attached. Testing before that point is cheaper in every direction, because a finding caught at design costs a revision and a finding caught at bid costs the bid. Tell us what you are shipping on a consult and we will scope the device coverage with you.
- Federal and public-sector RFPs
- Vendor onboarding and reviews
- Contract renewals
- New models and firmware releases
- Buyer documentation requests
Which devices Section 508 Chapter 4 covers
Chapter 4 applies whenever the ICT is a tangible device or has a physical component. In federal practice that means the following categories, and it applies to them whether the agency built the product, bought it, or is simply using it.
Three things sit outside it, and knowing that saves you money: assistive technology itself, non-electronic items, and passive components such as cables. If you are not certain your product carries the obligation at all, that is the first question we settle, before you buy testing you may not need.
What Section 508 Chapter 4 requires of hardware
Most accessibility vendors will tell you they test hardware. Very few will tell you against what. These are the provisions your device is measured on, in the order they appear in the standard, with the thresholds the text actually sets. They are also the headings your findings come back under.
Closed functionality
Devices a user cannot attach their own assistive technology to — kiosks, transaction machines, copiers — have to work on their own. That means speech output coordinated with what is on the screen, a way to raise the volume, and displayed characters at least 3/16 inch (4.8 mm) high with sufficient contrast.
Biometrics
Biometric identification cannot be the only way in, unless the device offers at least two options that use different biological characteristics. A fingerprint-only lock does not pass.
Preservation of information
Equipment that transmits or converts information must not strip out the accessibility information traveling with it, or must restore it on delivery. Captions that vanish through a conversion step fail here.
Privacy
The same degree of privacy of input and output has to be available to everyone. If a blind user has to have a PIN or a medical selection read aloud where bystanders can hear it, the device fails no matter how good the speech output is.
Standard connections
At least one connection of each type has to use a non-proprietary industry standard, so that a user can attach their own equipment to it.
Operable parts
The longest provision, and where most devices fail. Controls must contrast visually with the surface around them and be identifiable by touch without being activated. Where a key repeats, the delay before repeat has to be at least 2 seconds. Every control has to be operable with one hand, without tight grasping, pinching, or twisting, at no more than 5 pounds (22.2 N) of force. Reach is bounded at 48 inches (1220 mm) maximum and 15 inches (380 mm) minimum. Tickets, fare cards, and keycards need a tactilely discernible orientation.
Display screens
On stationary equipment, at least one display screen of each type has to be visible from a point 40 inches (1015 mm) above the floor space in front of it. Nothing on the screen may flash more than three times in any one-second period.
Status indicators
Every status indicator has to be discernible visually and by touch or sound. A power light with no audible or tactile equivalent does not pass.
Color coding
Color cannot be the only thing conveying information, indicating an action, prompting a response, or distinguishing one element from another.
Audible signals
Sound cannot be the only thing conveying information, indicating an action, or prompting a response. This is the mirror of the color provision, and it catches devices that signal completion with a beep and nothing else.
Two-way voice communication
Anything carrying two-way voice needs volume gain, magnetic coupling for hearing aids under ANSI/IEEE C63.19 for wireless and TIA-1083 for wireline, speech encoded to ITU-T G.722.2 or IETF RFC 6716 where digital encoding is used, caller identification that is both visible and audible, and support for TTY.
Closed caption processing
Equipment that plays video has to decode and display closed captions, or pass the caption data through to a device that can.
Audio description processing
The same obligation for audio description: decode and play it, or pass it through intact.
User controls for captions and audio description
The controls for captions and audio description have to sit at the same level of access as volume and program selection, not three menus deep.
Section 508 conformance is measured against WCAG 2.0 Level A and AA on the software side, which is the version the Revised 508 Standards incorporate by reference. We confirm the target with you before an engagement starts, because testing a device interface against 2.1 or 2.2 spends your budget on criteria your contract never asked for.
What ICT accessibility testing evaluates in real-world use
Hardware accessibility is decided by how a person physically engages with the product: whether they can reach the controls, work them, read what the device is telling them, and finish the task without help. Our evaluation is organized around those questions rather than around a generic checklist.
Placement and reach
We measure whether the device can be approached, reached, and operated the way it is actually deployed, against the 15 to 48 inch bounds the standard sets.
Controls and operability
Buttons, switches, keypads, and touch controls are checked for one-handed operation, grip demand, tactile discernibility, and visual contrast against their surround.
Operating force and contact-sensitive inputs
We measure the force a control actually takes and flag anything above the five-pound limit, along with inputs that depend on skin contact or a sustained press.
Display, indicators, and feedback
Screen visibility from the required viewing point, character size and contrast, flash rate, and whether status is conveyed by more than one sense.
Blind and low-vision interaction
Whether the whole task can be completed with speech output alone, whether that output tracks the screen, and whether privacy survives it.
Embedded interface and assistive technology
Where the device runs its own interface, we test it as software as well, applying WCAG through WCAG2ICT, and check assistive technology behavior on the platforms in scope.
How we test hardware accessibility
Our hardware accessibility testing service runs on the device itself, in the configuration you ship, because there is no other way to answer the questions the standard asks. No scanner can tell you whether a control takes more than five pounds of force, whether a status light is discernible by touch, or whether a blind user can complete a transaction without a bystander overhearing their PIN. Every one of those is a physical observation.
A hardware engagement runs as a manual pass through Chapter 4, provision by provision, with the numbers written down: reach heights, character heights, operating force, viewing angle, flash rate. Where the device carries an interface of its own, we test that as software as well and apply WCAG through WCAG2ICT, since an embedded screen is still a screen. Where it carries two-way voice, we check hearing-aid coupling and the caller identification path.
We record the product version, firmware, and configuration under test before we start. A conformance report that does not name what was evaluated cannot be defended when a reviewer asks, and that question always comes.
What you receive from a hardware accessibility engagement
Every engagement ends in documentation rather than a verbal debrief, and it is written to be used twice: once by your engineers, who need to know what to change and where, and once by a reviewer, who needs to see that the claims rest on something. Findings are prioritized by user impact and by what fails a federal review first, so the work lands in the order that de-risks the contract fastest.
- Findings mapped to the specific Chapter 4 provision each one fails, with location and evidence
- Recorded measurements for reach, force, character size, and viewing angle
- A stated scope: which models, versions, firmware, and configurations were covered
- Remediation guidance prioritized by user impact and by what a federal reviewer will look at first
- A retest after your engineering team makes the changes, confirming what is closed
- A VPAT completed as an ACR in the correct edition where procurement asks for one
VPAT and ACR reporting for hardware products
The VPAT is the template. Once it is completed with real evaluation results it is an Accessibility Conformance Report, and that is the document a buyer actually reviews. The two words get used interchangeably in procurement conversations, but there is no certification behind either of them and no authority that approves one. What a reviewer is judging is whether the report is credible.
That is why self-reported hardware VPATs draw more scrutiny rather than less. A vendor asserting its own conformance with nothing behind it gives a contracting officer no way to verify anything, so the safe move is to ask more questions. We write the report from testing we performed, which is what makes the conformance statements answerable.
What makes a hardware ACR ready for procurement
- The exact product, version, model, and configuration the report covers, stated up front
- The standard and edition used, so a reviewer knows which requirements the claims are measured against
- What was in scope and what was not, said plainly rather than left to inference
- Conformance statements that match the findings, not the marketing
- Remarks that explain a limitation in language a non-engineer can act on
Partially Supports is not a failure and should not be treated as one. It means the product meets the requirement in some situations and not others, and a reviewer who sees consistent, honest reporting will trust the rest of the document. An over-claimed Supports that collapses on the first follow-up question does far more damage than an accurate qualification.
Scope narrowly and say so. Buyers do not need to hear that everything is covered; they need to match the report against the thing they are about to purchase, which means naming the model and configuration rather than the product line. Where a European buyer is involved, the report is prepared against the EN 301 549 edition instead of the Section 508 one, and we confirm which applies before drafting.
An ACR is a point-in-time document. When firmware changes, when controls or the interface change, or when the version you ship is no longer the version that was tested, the report needs refreshing. We retest the affected areas rather than rebuilding the whole engagement.
Trusted by teams at
Common questions about hardware accessibility testing
A federal buyer asked for accessibility documentation on our device. What do we actually need?
Does Chapter 4 apply to our product, or only to the software running on it?
Do you test the actual device, or work from our specifications?
Our product is hardware plus a software interface. Is that one engagement or two?
Do we need a separate report for every model and configuration?
What happens if the device fails a requirement we cannot change on this generation?
Can an automated tool do any of this?
Do you retest after we make the changes?
We already sell this device commercially. Does that change what we need?
Can you work from testing our engineering team has already done?
Who does this work
David LoPresti works directly with technology manufacturers and government contractors to evaluate accessibility conformance and prepare the documentation buyers require during procurement and contract review. On a device engagement that means hands-on evaluation of the physical controls, the display, and the embedded interface against the Chapter 4 provisions, then findings your engineers can act on and, where a buyer asks for it, an ACR completed from the VPAT template that reflects what the testing actually found.
The standards this page refers to
- U.S. Access Board: the Revised Section 508 standards, including the hardware chapter
- The Revised 508 Standards in the Code of Federal Regulations (36 CFR Part 1194)
- Section508.gov: how federal testers approach hardware ICT
- The Section 508 statute in the U.S. Code (29 U.S.C. 794d)
- FAR Subpart 39.2: ICT accessibility requirements in federal acquisitions
- Section508.gov: creating an ACR from the VPAT template
- W3C: applying WCAG to non-web software, such as an embedded device interface
Get hardware accessibility settled before procurement review
Tell us what you are shipping, who is asking, and when they need it — we will scope the testing services and the conformance report with you on a call.
Free Consultation (opens in new tab)