Most usability advice is taste. Six requirements added in 2024 are not: they have numbers, they apply to your forms, and almost no B2B site meets them.
Most arguments about website usability are arguments about taste, which is why they never end. A smaller set of requirements is not: it has numbers, it applies directly to the forms and navigation of a B2B site, and it was updated recently enough that most sites have never been checked against it.
The current accessibility recommendation was published on 12 December 2024. It adds nine success criteria compared with the previous version, six of which sit at the conformance levels that policies actually reference. Several of them describe behaviours that any B2B site can fail in an afternoon of ordinary development.
This is not an accessibility article. It is a usability article that uses the only usability requirements anyone has bothered to write down with thresholds attached.
Six new requirements, and where B2B sites fail them
Each of these is testable by one person with a keyboard and a browser.
Focus must not be entirely hidden. “When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.” A sticky header or a cookie bar that covers the focused element fails this at AA.
With a nuance worth knowing. The AA version says “not entirely hidden”. A header covering half a focused button passes AA and fails the AAA version, which requires that “no part of the component is hidden.”
Dragging must have an alternative. “All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential.” Slider-based filters and drag-to-reorder interfaces need a non-drag path.
Targets have a minimum size, and it is 24 pixels. “The size of the target for pointer inputs is at least 24 by 24 CSS pixels”, with five exceptions including spacing, an equivalent control elsewhere on the page, and inline targets constrained by line height.
Do not confuse that with the number people quote. 44 by 44 pixels is a different criterion, at Level AAA, carried over from the previous version. 24 is the AA threshold; 44 is the aspiration.
Help has to sit in the same place. If help mechanisms are “repeated on multiple web pages within a set of web pages, they occur in the same order relative to other page content”. The listed mechanisms are human contact details, a human contact mechanism, a self-help option, and a fully automated contact mechanism. A chat widget that moves between templates fails this at Level A.
And nothing should be typed twice. “Information previously entered by or provided to the user that is required to be entered again in the same process is either: auto-populated, or available for the user to select.” Multi-step forms that ask for an email address on step one and again on step three fail this at Level A.
One of the six deserves its own section, because the fix is a single line of code and the failure is deliberate on most sites.
The requirement. “A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following”, followed by four alternatives: another method not relying on a cognitive test, a mechanism to assist, object recognition, or personal content.
And the mechanisms W3C names. “Support for password entry by password managers to reduce memory need, and copy and paste to reduce the cognitive burden of re-typing.”
Which turns a common security habit inside out. Blocking paste in a password field, or disabling autofill, removes one of the two things the standard names as satisfying the criterion. It is a conformance failure implemented on purpose.
The same logic reaches your client portal. Any login, any two-factor step, any “confirm your email” gate.
And a related criterion covers what happens when the session dies. At AAA: “When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating.” Most B2B portals fail this and lose the form.
With numbers for timeouts at Level A. A time limit must be adjustable to at least ten times the default, or the user must be “warned before time expires and given at least 20 seconds to extend the time limit with a simple action”, extendable “at least ten times”. Limits longer than 20 hours are exempt, on the reasoning that 20 hours “is longer than a full waking day.”
Form requirements are short, specific, and mostly about text rather than styling.
Labels, in one sentence. The whole criterion at Level A reads: “Labels or instructions are provided when content requires user input.”
Errors must be described in words. “If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.” A red border alone does not satisfy it, because a border is not text.
And a suggestion is owed where one is known. At AA: “If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.”
Fields collecting information about the user must be machine-identifiable. At AA, the purpose of each such field must be “programmatically determined”, which in practice means correct autocomplete tokens.
The tokens for a B2B contact form are already specified.name, given-name, family-name, organization (“Company name corresponding to the person, address, or contact information in the other fields”), organization-title (“Job title”), email, tel, url. Using invented values to defeat autofill breaks this.
And for anything with consequences. At AA, pages that “cause legal commitments or financial transactions”, modify or delete stored data, or submit test responses must offer one of three things: submissions are reversible, data is checked with an opportunity to correct, or a mechanism exists “for reviewing, confirming, and correcting information before finalizing the submission.”
The placeholder question, settled by the right document
This argument recurs on every project, and it is worth knowing where the answer actually lives.
The normative sentence is in the HTML Standard, not in WCAG. “The placeholder attribute should not be used as an alternative to a label.”
With the distinction spelled out. “The hint given by the control’s label is shown at all times; the short hint given in the placeholder attribute is shown before the user enters a value.”
And a correction worth making. No WCAG technique or Understanding document mentions placeholders at all. The failure often cited in this context concerns visually formatted phone-number field groups, not placeholders. Attributing a placeholder rule to WCAG is wrong even though the conclusion is right.
W3C’s own tutorial adds the practical reasons. Placeholder text “is not a replacement for labels. Assistive technologies, such as screen readers, do not treat placeholder text as labels.” And it “disappears from form fields when users start entering text”, which “makes it more difficult for users to check their responses before submitting.”
Plus a contrast observation. “Web browsers usually display the placeholder text in a color that does not meet the minimum contrast requirement.”
On required fields, one nuance most teams get backwards. Marking a field required in the visible label is the sufficient technique. The ARIA attribute is listed as advisory only, never sufficient on its own. Both, not either.
It would be dishonest to present a standard as a usability strategy, and the standard itself declines to make that claim.
On the ceiling. “Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive, language, and learning areas.”
On the scope. Following the guidelines “will not address every user need”, while also often making “web content more usable to users in general.”
And the working group’s own admission. “The Working Group considers that WCAG 2.2 incrementally advances web content accessibility guidance for all these areas, but underscores that not all user needs are met by these guidelines.”
W3C is also explicit about checklist thinking, in a page whose last substantive update was 2016: “when designers, developers, and project managers approach accessibility as a checklist to meet these standards, the focus is only on the technical aspects of accessibility. As a result, the human interaction aspect is often lost, and accessibility is not achieved.”
With the reverse caution in the same place. “Usability processes and user involvement alone cannot address all accessibility issues … Accessibility guidelines, standards, and techniques ensure that the wide range of issues are adequately covered.”
Which is the accurate framing for a B2B site. These criteria are the part of usability that can be settled by measurement rather than by opinion. They are not the whole of it, and passing them all does not mean people can use your site. They are still the first checks we run on a B2B website judged on the enquiries it produces, because every failure listed above sits on a form or in the navigation.
One housekeeping note if you maintain a conformance statement. The criterion on parsing was removed in the 2024 version, with the reason given: “Assistive technology no longer has any need to directly parse HTML … This criterion no longer has utility and is removed.”
Run the keyboard test first, because it costs ten minutes. Tab through your main form and your navigation and watch for two things: whether the focused element is ever hidden behind a sticky header, and whether the focus indicator is visible at all.
Then measure three targets: your icon-only buttons, your footer links, and any close cross on a modal. 24 by 24 CSS pixels, or adequate spacing under the exception.
Open your longest form and look for anything asked twice, then open your login and try to paste a password. Both are one-line fixes and both are current requirements.
Finally, read your error messages as text with the colour removed. If a message only exists as a red outline, it is not a message.
24 by 24 CSS pixels at Level AA, under the criterion added in 2024. The often-quoted 44 pixels belongs to a different criterion at Level AAA, carried over from the previous version.
Can a placeholder replace a form label?
No. The HTML Standard states normatively: 'The placeholder attribute should not be used as an alternative to a label.' Note this is the HTML spec, not a WCAG technique.
Is blocking paste in a password field a problem?
Yes. The accessibility criterion on authentication names copy and paste among the mechanisms that satisfy it. Blocking paste removes one of the things that makes the step conformant.
Does conformance mean the site is usable?
No, and W3C says so: 'even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability.'