Closed functionality: where WCAG stops being the right test
By David LoPresti July 27, 2026 The row that has no honest answer
You are filling in the WCAG table of an Accessibility Conformance Report for a self-service device. GSA’s worked WCAG row prints five component lines to answer against: Web, Electronic Docs, Software, Closed, Authoring Tool. You are on the Closed line for 1.4.3 Contrast (Minimum). The screen is fixed behind a bezel, the platform will not let a tool read the rendered colors, and the tester has attached a photograph of the display with a sampled swatch marked on it.
One published document says that photograph is not evidence. A second says the criterion should not have been pointed at the hardware in the first place. A third, the one with legal force, says the device is excused from interoperating with assistive technology at all. Three answers, and the row still needs a word in it.
That collision is not an editing problem. It is the seam between two documents that answer different halves of one question and never say where the first stops. WCAG2ICT, the W3C Group Note published 11 December 2025, says which WCAG success criteria break on a closed device and why. It then declines, on the record, to say what belongs in their place. The Revised 508 Standards do that job in Chapter 4, in their own vocabulary, with their own numbers, and with two flagged criteria left uncovered by any provision.
This article works that seam. It reads the closed-functionality appendix of the current WCAG2ICT Note against the codified text of 36 CFR part 1194, shows how many of the 34 flagged criteria actually reach a Section 508 report, names the Chapter 4 provisions that address the rest, and says where the sources checked here publish no answer at all. Quotes come from the eCFR versioner API at the 19 August 2026 issue date of title 36, and from the WCAG2ICT source at its 11 December 2025 publication commit.
The regulation’s definition, and WCAG2ICT’s narrower reading
The regulation defines the term for Section 508 purposes in Appendix A at E103.4, and the Revised 255 Guidelines carry a shorter twin at C103.4 with the examples stripped. E103.4 is the definition with legal effect in a Section 508 report:
Closed Functionality. Characteristics that limit functionality or prevent a user from attaching or installing assistive technology. Examples of ICT with closed functionality are self-service machines, information kiosks, set-top boxes, fax machines, calculators, and computers that are locked down so that users may not adjust settings due to a policy such as Desktop Core Configuration.
Two things in that sentence get skipped. A locked-down desktop is in the list, so closed functionality is not a synonym for a machine bolted to a floor. And the test is about attaching or installing, not about physical form.
The Access Board stated it as a clean either/or in the 2017 final-rule preamble at 82 FR 5790 (18 January 2017), in its response to comments on closed functionality, answering copier manufacturers who argued that magnification and assistive technology support should relieve them of speech output:
If ICT is capable of attaching assistive technology, then by definition it is not considered to have closed functionality, and the provisions on speech-output for closed functionality do not apply (proposed E103; final E103; proposed C103; final C103).
WCAG2ICT introduces closed functionality as a new key term in this edition and defines it more tightly, as “a property or characteristic that prevents users from attaching, installing, or using assistive technology.” The word that matters there is property. The Note’s own examples split products down the middle rather than sorting them into two bins. It describes an ebook reader “that allows assistive technologies to access all of the user interface controls of the ebook program (open functionality) but does not allow the assistive technologies to access the actual content of book (closed functionality),” and an operating system that requires login credentials before assistive technology can load, where “The login portion would be closed functionality.” The two readings pull against each other. The Board’s sentence is an either/or about a product. The Note’s is about a property one product can have in one place and not in another, and the Note is informative.
The appendix pushes the same point onto individual criteria. It says other success criteria still apply where ICT is “partially closed” or accepts some types of device, and gives 2.1.1 Keyboard as the example: it applies to ICT “that is closed to screen readers, but have a physical keyboard, a connector for standard keyboards, or allow the installation of alternate keyboards.” A device closed to screen readers but fitted with a keyboard port does not get to drop 2.1.1.
One boundary comes before all of this. Chapter 4 excludes assistive technology itself: 401.1 carries the exception “Hardware that is assistive technology shall not be required to conform to the requirements of this chapter.”
And the counterweight, which the Note states in two places: closed does not mean inaccessible. Some of these products, “though closed to some external assistive technologies, often have extensive internal accessibility features that serve as assistive technology,” and others are open to some categories of assistive technology and not others. A finding of closed functionality opens a different requirements set. It is not a defect.
View the data as a table
| Revised 508 Standards, E103.4 | WCAG2ICT Note, 2025 | |
|---|---|---|
| Standing in a Section 508 report | The definition with legal effect in the report | Informative; the Note is not a standard |
| What the term describes | A characteristic of the ICT as a whole | A property one product can have in one place and not another |
| The test applied | Either/or: if AT can attach, it is not closed | Per function: one product can be open in one place, closed in another |
| Worked examples | Self-service machines, kiosks, set-top boxes, fax machines, calculators, locked-down computers | An ebook reader open for its controls, closed for book content |
| What the test is not about | Not physical form; attaching or installing is the test | 2.1.1 Keyboard still applies to ICT closed to screen readers with a keyboard port |
The sentence that switches the test, and the exception that makes it stick
Chapter 4 opens the closed-functionality section with a single operative sentence, at Appendix C, 402.1:
402.1 General. ICT with closed functionality shall be operable without requiring the user to attach or install assistive technology other than personal headsets or other audio couplers, and shall conform to 402.
Read that against the software chapter and the design becomes obvious. Appendix C, 502.1 states the general software duty and then removes it for closed products:
502.1 General. Software shall interoperate with assistive technology and shall conform to 502.
EXCEPTION: ICT conforming to 402 shall not be required to conform to 502.
This is the codified counterpart of everything WCAG2ICT says about the missing user agent, and it is the provision that gets left out of the discussion. Section 508 does not ask a kiosk to expose an accessibility API. It asks the kiosk to talk. The exception is conditional, and the condition is doing the talking: it is available to “ICT conforming to 402,” so a device that fails its speech-output obligations does not also get to shed 502. Failing 402 costs you the interoperability exception, and 503 Applications and 504 Authoring Tools were never inside it.
Three scoping provisions route a product into that trade. E206.1 sends hardware into Chapter 4 where it transmits information or has a user interface. E207.2 sends software to WCAG, “Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0.” E204.1 catches the remainder: “Where the requirements in Chapters 4 and 5 do not address one or more functions of ICT, the functions not addressed shall conform to the Functional Performance Criteria specified in Chapter 3.” How Chapter 3’s nine criteria land in a report is covered in functional performance criteria as ACR rows.
Chapter 4 runs from 401 to 415. It has been amended once since the final rule at 82 FR 5790: the direct final rule at 83 FR 2912, published 22 January 2018 and effective 23 March 2018, which added 412.8 Legacy TTY Support.
Why WCAG cannot answer for a closed device
WCAG2ICT is explicit about the assumption that fails. Its closed-functionality section opens with it:
As noted in the Introduction, WCAG 2 assumes the presence of a “user agent” such as a browser, media player, or assistive technology as a means to access web content. Many of the success criteria in WCAG 2 assume web content will be accessed by ICT where assistive technologies can be connected to it or installed on it.
Then the conclusion: “To the extent the ICT is closed, following the WCAG success criteria by themselves will not ensure that non-web software is accessible.”
For hardware the Note does not hedge:
There are existing standards that specify accessibility requirements for both hardware and software aspects of ICT with closed functionality. This document does not comment on those standards, but does note that WCAG success criteria should not be applied to hardware aspects of ICT with closed functionality.
The Introduction gives the reason in scope terms: “This document does not comment on hardware aspects of products because the basic constructs on which WCAG 2 is built do not apply to hardware.” A WCAG finding written against a bezel, a keypad, a card reader or a screen’s physical contrast is a finding written outside the standard it cites. That is not a stylistic objection. It is the Note saying the tool does not fit the workpiece.
Two limits on the Note itself belong next to that. It is a W3C Group Note, informative and not on the Recommendation track, and it says so about itself in one line: “WCAG2ICT is not a standard, so it is not possible to conform to WCAG2ICT.” And the Task Force declines the follow-up question. It says it is outside its work statement “to say what additional measures are needed,” and that what WCAG2ICT does instead is point out which success criteria depend on assistive technologies. So the document that diagnoses the problem does not prescribe, and nothing in it takes effect on any date.
What it does supply is Appendix A, a list of 34 success criteria that “can be problematic for developers of ICT with closed functionality,” each with a stated reason. It tells implementers to weigh the criteria “on a criterion-by-criterion basis” and warns that “Alternate accessibility provisions might be needed.”
Read the 34 reasons together and they fall into a small number of causes: nothing to expose information to, because there is no accessibility API and no assistive technology; a text alternative with nowhere to go; a presentation the software author does not control; a display that cannot rotate; a platform that cannot re-render text the way a browser can; no keyboard or no focus; a unit of measurement that is not native; and one criterion withdrawn in WCAG 2.2. That grouping is ours. The appendix is alphabetical by criterion number and asserts no categories. The reason text is the Note’s.
Flagged is also not failed. Four of the 34 entries resolve outright, and a fifth resolves in a stated case. For 2.1.2 No Keyboard Trap and 2.4.7 Focus Visible, where the keys are mapped directly to functions, “there is no concept of focus” and the criterion is satisfied. For 2.1.4 Character Key Shortcuts, where operation “revolves around a single key performing a single function,” the appendix says “this success criterion is satisfied.” For 4.1.1 Parsing, it says the criterion was made obsolete in WCAG 2.2 and “is not applicable.” And under 1.4.10 Reflow, where a device shows only UI controls and no large chunks of text, two-dimensional scrolling “may be considered essential, thus meeting an exception, and the success criterion would be satisfied.”
Thirty-four flagged, sixteen to eighteen live in a Section 508 report
Here is the part that changes how a hardware report is scoped, and it is arithmetic rather than opinion. The 34 flagged criteria are not 34 rows a Section 508 tester has to argue about, because Section 508 does not require 34 of them.
The rule pins its WCAG hook to one dated document. Appendix C, 702.10.1 incorporates “WCAG 2.0, Web Content Accessibility Guidelines, W3C Recommendation, December 11, 2008,” and E207.2 requires Level A and AA of that version. WCAG2ICT covers WCAG 2.0, 2.1 and 2.2. Its Introduction, under Comparison with the 2013 WCAG2ICT Note, lists the criteria added for the later versions, and twelve of the 34 flagged entries are on those lists: 1.3.4, 1.3.5, 1.4.10, 1.4.11, 1.4.12, 2.1.4, 2.5.2, 2.5.3 and 4.1.3 arrived in WCAG 2.1, and 2.5.8, 3.2.6 and 3.3.8 arrived in WCAG 2.2. None of the twelve is a Section 508 requirement. Twenty-two flagged entries remain.
Then the regulation removes four more by name. E207.2 Exception 2 reads: “Non-Web software shall not be required to conform to the following four Success Criteria in WCAG 2.0: 2.4.1 Bypass Blocks; 2.4.5 Multiple Ways; 3.2.3 Consistent Navigation; and 3.2.4 Consistent Identification.” Those are exactly the criteria WCAG2ICT flags because they turn on “sets of software programs,” which the appendix calls variously “extremely rare,” “exceedingly rare” and “very rare” on closed ICT. Regulator and Note reached the same conclusion by different routes, and the regulator got there first, in 2017. Eighteen remain.
Subtract the two that the appendix itself resolves as satisfied on a device with no focus, 2.1.2 and 2.4.7, and sixteen entries are left where a Section 508 software table genuinely has to reckon with the closed-functionality problem: 1.1.1, 1.2.1, 1.2.3, 1.3.1, 1.3.2, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 2.1.1, 2.4.4, 3.1.1, 3.1.2, 3.3.1, 4.1.1 and 4.1.2.
That last step is the one that moves. The first two subtractions are unconditional, because the regulation says so on its face. The third holds only where the appendix’s condition holds: it resolves 2.1.2 and 2.4.7 for ICT where “the keys are mapped directly to functions without moving focus between on-screen controls” and therefore “there is no concept of focus.” Where the closed device does move an on-screen focus, both rows stay in scope and the count is eighteen. Establish which of the two the device is before you scope the table.
One of those sixteen carries a trap. WCAG2ICT marks 4.1.1 Parsing not applicable because WCAG 2.2 removed it. Section 508 is not on WCAG 2.2. Under 702.10.1 the rule still incorporates the 2008 Recommendation, in which 4.1.1 is a Level A criterion, so the Note’s reasoning does not delete that row from a Section 508 report. The same caution runs the other way for the twelve version-added entries: citing WCAG2ICT guidance on 1.4.11 or 3.3.8 inside a Section 508 conformance claim is citing guidance about a criterion the rule does not require. If you owe both Section 508 and a WCAG 2.1 obligation, the version matrix is set out in which WCAG version each US rule requires.
View the data as a table
| Stage | Detail |
|---|---|
| 1. 34 flagged by WCAG2ICT | Section 508 does not require 34 of them, so they are not 34 rows a tester has to argue about |
| 2. 22 after the version filter | Twelve of the 34 arrived in WCAG 2.1 or 2.2; the rule incorporates the 2008 WCAG 2.0 Recommendation |
| 3. 18 after E207.2 Exception 2 | Non-web software is excepted from 2.4.1, 2.4.5, 3.2.3 and 3.2.4 by name |
| 4. 16 with no focus | Where keys map directly to functions |
Where Chapter 4 addresses the same user need
One caution before the mapping. The grouping below is ours except where the Note names the regulation itself, and it maps user needs, not obligations. Conforming to 402 does not answer a WCAG row. E207.2 applies to the software on the device whether or not 402 is met, and the only relief the rule grants a closed device is 502.1’s exception from interoperability. A speech-enabled kiosk still owes an answer on 1.1.1 and 4.1.2.
The largest group of flagged entries turns on one phrase: programmatically determinable. Nine Appendix A entries rest on it, and the six that survive the Section 508 version filter are 1.1.1, 1.3.1, 1.3.2, 2.4.4, 3.3.1 and 4.1.2. All of them assume something downstream is reading a name, a role, a relationship or an error out of the interface. On a closed device nothing is.
Chapter 4 reaches the same user need with sound instead of structure. 402.2 requires that “ICT with a display screen shall be speech-output enabled for full and independent use by individuals with vision impairments,” and 402.2.1 sets the coverage: “Speech output shall be provided for all information displayed on-screen.” 402.2.2 adds transactional verification, 402.2.3 delivery and coordination with the screen, 402.2.4 interrupt, repeat and pause, and 402.2.5 contracted braille instructions for starting speech mode. Six numbered exceptions qualify 402.2, including one permitting conformance to 409 in place of speech output where memory or processor constraints make speech impossible. That fallback asks far less: 409.1 says only that “Where provided, status indicators shall be discernible visually and by touch or sound.” Record which exception a vendor claims, by number.
For the audio-control entry, WCAG2ICT points at the regulation by name. Its note under 1.4.2 says “there are existing requirements in regulations (e.g., the EN 301 549 and U.S. Revised 508 Standards) that address volume control for ICT with closed functionality.” Those are 402.3.1 for private listening and 402.3.2 for non-private listening, which requires “incremental volume control shall be provided with output amplification up to a level of at least 65 dB.” That is a floor on the level the control must be able to reach, not on the output itself. For the keyboard entry, 407.3 requires at least one input control for each function, and 407.3.1 requires that input controls be “operable by touch and tactilely discernible without activation.”
Chapter 4 also carries requirements WCAG has no analogue for, which is the same seam running the other way. 405.1 is the sharpest: “When speech output required by 402.2 is enabled, the screen shall not blank automatically.” No WCAG criterion contemplates a privacy design that hides the screen from a bystander while a blind user listens. Nor does WCAG set a five-pound activation force ceiling for operable parts (407.6), a reach range for at least one of each type of operable part on stationary ICT (407.8), or the 408.2 rule that, “Where stationary ICT provides one or more display screens,” at least one of each type be “visible from a point located 40 inches (1015 mm) above the floor space where the display screen is viewed.”
Two flagged criteria are left genuinely unanswered. Under 1.4.10 Reflow the appendix says that “some other non-WCAG requirements would be needed for ICT with closed functionality to ensure that content is readable by persons with low vision without scrolling in two dimensions,” and it names none. And 2.5.8 Target Size has no Chapter 4 counterpart, because 407 reaches physical operable parts and nothing in Chapter 4 sets an on-screen target dimension. That second judgment is ours: the Note’s own 2.5.8 entry is about CSS pixels, not about a missing provision.
Two more look like gaps and are not. 1.3.4 Orientation is routed by the Note to the essential exception, because fixed-in-place displays cannot rotate, so the criterion is satisfied rather than unanswered. And 1.4.12 Text Spacing says the opposite of a gap: the ability to modify spacing “is rarely supported” on closed ICT, but “the success criterion applies as written.” 1.4.10, 1.4.12, 1.3.4 and 2.5.8 all arrived in WCAG 2.1 or 2.2, so none of them falls inside a Section 508 claim in any case, but a buyer writing contract requirements against 1.4.10 or 2.5.8 is choosing values with no standard to cite.
View the data as a table
| Programmatically determinable | Audio control | Keyboard input | Reflow and target size | |
|---|---|---|---|---|
| Flagged WCAG criteria | 1.1.1, 1.3.1, 1.3.2, 2.4.4, 3.3.1, 4.1.2 | 1.4.2 Audio Control | 2.1.1 Keyboard | 1.4.10 Reflow, 2.5.8 Target Size |
| Chapter 4 provision | 402.2, rows 402.2.1 to 402.2.5 | 402.3.1 and 402.3.2 | 407.3 and 407.3.1 | None |
| What it requires | Speech output for all on-screen information | Volume control to at least 65 dB | One control per function, touch discernible | None; no text to cite |
| Inside a Section 508 claim? | Yes, all six | Yes | Yes | No, both are WCAG 2.1 or 2.2 |
Contrast is the place where the evidence question gets sharp
Take the row from the opening. WCAG2ICT carries a note under 1.4.3 Contrast (Minimum) and again under 1.4.11 Non-text Contrast that reads, in full: “Contrast requirements for hardware are out of scope for WCAG2ICT (and this success criterion).” So the hardware half of the question is not a WCAG question at all.
For the software half on a locked-down platform, the appendix is unusually direct about who can and cannot produce evidence:
When the color contrast ratio cannot be programmatically measured due to system limitations (e.g. lockdown), precise quantifiable testing of color contrast cannot be performed by a third party. In such cases, the software author would need to confirm that the color combinations used meet the contrast requirement.
It then closes the obvious workaround, in a note stating that photographs “are not sufficient for testing that content meets this success criterion,” because lighting, camera and the physical display distort the capture. What a buyer does with that in a solicitation is worked out in kiosk ADA compliance: RFP requirements and acceptance tests. What concerns a report writer is the exact wording, and that wording sits under 1.4.3. The parallel note under 1.4.11 is shorter and drops the parenthetical about the hardware display, so do not attribute the longer form to 1.4.11.
Now the harder half. Chapter 4 sets no contrast ratio and no measurement method. 402.4 requires that characters on a display screen “contrast with their background with either light characters on a dark background or dark characters on a light background,” and sets a height floor of “3/16 inch (4.8 mm) high minimum based on the uppercase letter ‘I’” where the ICT provides no screen enlargement feature. 407.2 applies the same polarity rule to keys and controls. Neither states a number. The 2010 ADA Standards do the same at 707.7.2, in a section titled Automatic Teller Machines and Fare Machines: sans serif, the same 3/16 inch minimum, the same polarity, no ratio.
So on a hardware contrast row there is no ratio in the governing standard to measure against, and anyone who writes 4.5:1 into a Chapter 4 row has imported it from elsewhere and owes the reader a citation for where. On the software side, WCAG2ICT rules out the photograph and stops. It names no substitute artifact, no instrument, no tolerance and no acceptable capture method, and it does not say what form the software author’s confirmation should take or what a reviewer should accept as proof of it. That gap is not ours to fill by assertion.
View the data as a table
| Hardware display contrast | Software contrast, locked down | |
|---|---|---|
| Does WCAG2ICT cover it? | No: hardware contrast is out of scope for WCAG2ICT and for the criterion | Yes, and the appendix is direct about who can produce evidence |
| What the governing text states | 402.4: light characters on dark, or dark on light. No ratio | The software author confirms the color combinations meet the requirement |
| Who can measure it | No source names an instrument, fixture or tolerance | Not a third party, where system lockdown blocks measurement |
| Is a photograph acceptable? | The question is not a WCAG question at all | No: photographs are not sufficient for testing the criterion |
| What no source supplies | A contrast ratio or a measurement method in Chapter 4 | A substitute artifact, instrument, tolerance or capture method |
Where the answer lands in the report
GSA’s how to create an ACR with a VPAT sets out the container: “There are four Revised Section 508 tables, labeled as Chapter 3 (Functional Performance Criteria), Chapter 4 (Hardware), Chapter 5 (Software), and Chapter 6 (Support Documentation and Services). Complete the applicable tables.” Each row takes one of four phrases, whose definitions reward literal reading: Does Not Support is “The majority of product functionality does not meet the criterion,” while Partially Supports is “Some functionality of the product does not meet the criterion.”
One phrase inside the Supports definition carries more weight on a closed device than it looks: functionality that “meets with equivalent facilitation.” In the regulation that is E101.2, which permits “an alternative design or technology that results in substantially equivalent or greater accessibility and usability,” judged by the Chapter 3 functional performance criteria. It is the route the rule gives a closed device to answer a requirement its own way, and a report that takes it should say so in remarks and point at the Chapter 3 table rather than leaving the reader to infer it.
Two structural details decide where the closed-functionality reasoning goes. In GSA’s worked 402 block, the lines at 402, 402.1 and 402.2 print as “Heading cell - no response required,” and the answerable rows are 402.2.1 through 402.2.5, so the sentence carrying the whole doctrine is not a row anybody scores. And the Closed component line, the one from the opening of this article, exists only in the WCAG table. The Chapter 4 table has no such split.
That turns the partially-closed problem into a documentation problem. A product can be open for its controls and closed for its content, or closed to screen readers and open to keyboards, but the report takes one answer per criterion per component, and neither GSA’s how-to page nor ITI’s VPAT materials publishes a convention for recording which functions are the closed ones. If it matters to a buyer, it goes in the remarks column or the solicitation, not in the conformance level.
Now put a word in the row this article opened with: 1.4.3 on the Closed line for a locked-down device. Where the software author confirms that the color combinations meet the ratio, the row is Supports, and the confirmation goes in remarks with the name of whoever gave it. Where no confirmation exists and the only artifact offered is a photograph, the row cannot honestly read Supports, because Supports means the functionality “has at least one method that meets the criterion without known defects” and a photograph establishes nothing of the kind. Either obtain the confirmation before the report ships, or state in remarks that the criterion was not tested by an acceptable method. The phrase “not evaluated” is not available here: GSA reserves it for the Level AAA table. And where the contrast is fixed by hardware the software author cannot modify, that fact and the Note’s out-of-scope sentence belong in remarks, not in an argument that the row passes.
Check one more discrepancy before exporting. GSA’s page, footer dated June 2026, says the current VPAT is 2.4 and that any 2.x is acceptable. ITI’s own page offers VPAT Version 2.5Rev, dated April 2025. Both statements are live. Name the edition you used in the header.
What the sources do not settle
Six honest gaps, each of which changes what a report can claim.
- No decision construing 402 is cited anywhere in the sources used here. The Access Board’s and GSA’s published materials on closed functionality point to the text of the standard and to assessment guidance, and neither cites a tribunal applying it. This article cites none either. Nobody should represent 402 as judicially interpreted on the strength of it.
- The Access Board’s self-service machine rulemaking has not moved past an advance notice. The ANPRM at 87 FR 57662 published 21 September 2022, comments closed 21 November 2022, and the Board’s self-service transaction machines page still lists the next steps as analyzing comments and developing a preliminary regulatory impact analysis. The Board says there that it “is also considering incorporating certain requirements in the Revised 508 Standards for ‘closed’ hardware into a proposed rule.” Considering, not proposed.
- Nothing reconciles the WCAG version gap for federal procurement. The rule incorporates the 2008 Recommendation; the interpretive Note covers three versions; and the Note cannot bridge them, because it is not a standard.
- WCAG2ICT declines to say what replaces a flagged criterion, and Chapter 4 leaves 1.4.10 Reflow and 2.5.8 Target Size without a counterpart provision. 1.3.4 and 1.4.12 resolve inside the Note itself, under the essential exception and as applying on their own terms, so they are not gaps in the regulation.
- Neither GSA nor ITI publishes a convention for recording partial closure, as above.
- No source cited here states any contrast ratio, instrument, tolerance or acceptable evidence artifact for a hardware display. Chapter 4 states polarity, the ADA Standards state polarity, and WCAG2ICT excludes hardware contrast from its own scope.
What to do with the next hardware report
Take the last closed-functionality report you sent or received and check five things in order.
- Check whether the closure finding was made per function or per product. The per-function reading is WCAG2ICT’s, and WCAG2ICT is not a standard; the regulation defines a characteristic of the ICT and the Board’s preamble states it as an either/or. Where a product is open for some functions and closed for others, say so in remarks and in the solicitation, and do not expect the conformance level alone to carry it.
- Confirm the Chapter 4 table exists and is populated, and that 402.2 exception claims are recorded by number rather than described in prose.
- Confirm no WCAG finding is written against a hardware characteristic. If a row cites 1.4.3 or 1.4.11 for a bezel, a keypad or the physical display, it is outside the criterion’s own scope.
- Confirm the WCAG rows in scope are the WCAG 2.0 Level A and AA set, and that 2.4.1, 2.4.5, 3.2.3 and 3.2.4 are handled under E207.2 Exception 2 rather than argued from first principles.
- Confirm that any contrast evidence is not a photograph, and that where the platform is locked down the file records the software author’s confirmation and who gave it.
Two boundaries. Whether a procurement may accept a vendor’s self-confirmation of contrast on a locked-down platform is a contracting officer’s judgment under the solicitation, not a testing question, and it should be settled in writing before test starts rather than argued at delivery. And where the same device is also an ATM or a fare machine, the 2010 ADA Standards apply on their own terms and their own enforcement path, which is a question for the entity’s ADA counsel. Advisory 707 states the limit in one line: “Interactive transaction machines (ITMs), other than ATMs, are not covered by Section 707.” The buyer-by-buyer version of that analysis is in kiosk ADA compliance: RFP requirements and acceptance tests.
All of the above is a reading of published standards and of what evidence answers them. It says nothing about who owns which meter, and it should not: no source here names an instrument, a fixture or a tolerance for a hardware measurement, so a report that names one is going beyond the standard and should say where the number came from.
If you are producing or reviewing a conformance report for a closed device, ADACP’s hardware accessibility testing scopes the applicable Chapter 4 set and the WCAG rows that survive the version filter before testing starts, and our work with hardware manufacturers exists to get that decision made once rather than renegotiated at delivery. Send the product description and the draft report, and the first thing back is the list of rows currently answered against the wrong standard.