A developer is adding a control that opens a settings panel. Should it be a native HTML button, or could another element be styled to look like one? They want to understand what the browser provides, how keyboard users will operate it, and what assistive technology will recognize.
One reference leads to WHATWG, another to W3C, and another to WAI. These names do not represent three competing answers. They identify related parts of the web standards ecosystem, where different documents address different parts of the question.
WHATWG maintains important web-platform specifications, including HTML. W3C develops standards across a broader range of web technologies. WAI is the Web Accessibility Initiative within W3C. Knowing those roles helps readers find a reference. Understanding the particular document’s purpose, scope, and status helps them use it correctly.
What WHATWG, W3C, and WAI do
WHATWG: specifications for the web platform
The Web Hypertext Application Technology Working Group, usually shortened to WHATWG, maintains specifications including HTML, the DOM, Fetch, and URL. These describe foundational parts of how the web works.
For the developer choosing a button, the relevant resource is the HTML Living Standard. It describes the button element, its attributes, and its behavior within HTML. The WHATWG FAQ provides context about WHATWG’s work and its Living Standard approach.
W3C: standards work across web technologies
The World Wide Web Consortium, or W3C, brings together participants to develop web standards and related guidance. Its work includes areas such as CSS and accessibility. Particular working groups develop particular specifications; “published by W3C” does not mean every document has the same purpose or maturity.
The W3C standards overview is a useful starting point for that broader landscape. When investigating a specific requirement, however, the document itself is usually the better destination.
WAI: accessibility work within W3C
The Web Accessibility Initiative, or WAI, is part of W3C—not an independent standards organization alongside it. WAI brings together accessibility standards work and supporting resources, including educational material and evaluation guidance.
Resources associated with WAI include the Web Content Accessibility Guidelines (WCAG), WAI-ARIA, and the ARIA Authoring Practices Guide (APG). These resources have different jobs. WCAG provides accessibility requirements for web content; WAI-ARIA specifies accessibility semantics; APG offers implementation guidance for interface patterns.
The boundaries are not exclusive subject divisions. HTML includes accessibility-relevant features, while accessibility specifications refer to HTML and other platform technologies. Following those connections is part of reading the standards.
Following the button question through the sources
Consider an illustrative implementation: a control opens a settings panel on the current page. The developer is considering these two elements:
<button type="button">Open settings</button>
<div role="button">Open settings</div>These are not functionally equivalent. The second line declares a role, but that declaration does not supply native button behavior. Three source questions help explain the difference.
What does the HTML element provide?
The HTML Living Standard’s definition of the button element explains the native element and its attributes. An ordinary enabled button participates in the browser’s native focus and activation behavior.
Here, type="button" explicitly identifies a general-purpose button rather than a submit button. That matters if the control is placed inside a form. Application code still needs to open the panel; native HTML supplies the control, not the application’s entire interaction.
This is the first reason to consult HTML: establish what the element means and what behavior the platform already provides. The broader principle is covered in semantic HTML foundations.
What accessibility outcomes should be evaluated?
WCAG addresses the accessibility of the resulting content and functionality. In WCAG 2.2, Success Criterion 2.1.1, Keyboard, concerns operating functionality through a keyboard interface. Success Criterion 4.1.2, Name, Role, Value, concerns programmatically determinable information about user interface components.
These requirements lead to practical questions: can someone operate the control without a pointer? Can software determine its name and role? Where relevant, are its states and changes available to assistive technology?
Those are not the only accessibility considerations. Focus visibility, focus order, and the behavior of the opened panel may also matter. A native button is a useful starting point, not proof that the whole interaction meets WCAG.
What must an implementation actually do?
The APG button pattern describes expected button interaction, including activation with Enter and Space, and explains relevant roles, states, and properties.
Adding role="button" to a div does not make it keyboard-focusable or implement keyboard activation. Those behaviors would need to be supplied separately. The native element already provides the basic button interaction, leaving less behavior for the developer to reproduce.
For this ordinary action, the developer chooses the native button. The choice follows from the control’s purpose and platform behavior—not from a rule that custom controls are always forbidden. For more on that distinction, see when ARIA is unnecessary.
Requirements, explanations, and implementation guidance
An official source can specify requirements, explain them, document a technique, or illustrate a pattern. These functions complement one another, but they should not be treated as interchangeable.
Normative material defines requirements within a stated scope
Normative material establishes requirements or definitions that apply within the document’s scope. A specification may address authors, browser implementers, or other audiences. Before applying a passage, check whom it addresses and under what conditions.
A specification can also contain informative sections. Its own conventions explain which material is normative and how requirement terms are used. An explanatory note does not automatically have the same status as a conformance requirement beside it.
Understanding documents explain WCAG
The Understanding WCAG 2.2 documents are informative supporting resources. They explain the intent of success criteria, describe benefits, and connect readers with examples and techniques.
They do not add new WCAG success criteria. Their value is interpretive: they help a reviewer understand what a requirement is trying to achieve and how it applies.
Techniques describe ways to meet requirements
Techniques for WCAG 2.2 is also informative. It includes sufficient techniques, advisory techniques, and documented failures.
A sufficient technique can provide a way to satisfy a criterion when its stated conditions are met. It is not necessarily the only way. Advisory techniques offer additional improvements, and failure techniques describe situations that fail particular criteria.
WCAG conformance depends on meeting the applicable requirements, not on using every listed technique or copying a particular example.
APG guides implementation rather than defining WCAG conformance
The ARIA Authoring Practices Guide provides informative guidance about accessible interaction patterns and the use of ARIA. It is distinct from the WAI-ARIA specification and from WCAG.
APG patterns are useful for understanding expected interaction. Its examples still need evaluation before production use, including attention to their support notes and the environment in which they will operate.
Informative does not mean unimportant. It means the resource supports understanding or implementation rather than establishing the conformance requirement itself.
Reading a document’s status
Before relying on a passage, take a moment to identify the document around it. A search result may lead to a maintained reference, an older publication, or a draft with a familiar title.
- Confirm the title and scope. Is this a specification, an explanation, a technique, or an example?
- Identify responsibility. Which organization and, where stated, which working group maintains it?
- Read the status information. Look for labels such as Living Standard, Recommendation, Working Draft, or Editor’s Draft, and read what the document says about that status.
- Check the version or date. Is this the reference intended for the work, or a different edition?
- Look for replacement notices. Is the document superseded, obsolete, or linked to a newer maintained resource?
- Check the passage’s audience. Does it address content authors, implementers, or another group?
The HTML Living Standard is continuously maintained. “Living” does not mean that every part is experimental or that every browser implements every change immediately.
WCAG 2.2 illustrates a versioned W3C Recommendation. A Recommendation has completed the relevant W3C standards process, but that status does not certify individual websites or guarantee universal implementation support. Dated publications can provide stable references; they can also acquire later corrections or successor publications.
Drafts serve a different purpose. They may contain useful emerging work, but their status notices describe their maturity and limits. WHATWG and W3C do not use one identical publication model, so read the source’s terminology rather than imposing a single status ladder.
For a WCAG evaluation, record the version and conformance level being used. Newer material may help understanding without silently changing the evaluation’s baseline. Determining legal or contractual obligations is a separate question from interpreting a technical document’s status.
Connecting specifications with implementation evidence
The developer now has a reasoned element choice, relevant accessibility requirements, and guidance about interaction. The remaining question is whether the finished interface behaves as intended.
A specification describes what conforming behavior should be. Testing provides evidence about what happens in particular conditions. Neither replaces the other.
For the settings control, a focused review would examine whether:
- The button can be reached and operated by keyboard, with visible focus.
- Its accessible name and role accurately identify its purpose.
- Opening and closing the panel leaves focus in an appropriate place for the chosen interaction.
- Relevant states and changes are exposed correctly.
- The interaction works in the browser and assistive-technology combinations being supported.
Browser accessibility inspection tools can help reveal exposed semantics. Keyboard checks and testing with relevant assistive technologies examine actual operation. Where support is uncertain, consult implementation documentation, known issues, and appropriate tests rather than assuming that a specification alone proves availability.
Likewise, one browser’s observed behavior does not redefine the specification. This distinction is central to browser interoperability and to careful standards-based review.
When references appear to disagree
Apparent disagreement often begins with documents answering different questions. An HTML definition may describe a native control, while an APG pattern explains what an author must provide when implementing a custom interaction.
Advice to use native HTML and guidance for implementing an ARIA button are therefore not inherently contradictory. One helps with element choice; the other describes the responsibilities that accompany an implementation.
Before deciding that two sources conflict, compare their:
- Subject and implementation conditions.
- Intended audience.
- Version and publication status.
- Normative or informative role.
- Cross-references and stated relationship to other documents.
There is no useful universal rule that one organization’s name always outranks another’s. The relevant authority depends on the specific question and documents.
If the conflict remains unresolved, preserve the exact passages and implementation conditions. Follow authoritative cross-references and relevant issue discussions. A clearly recorded uncertainty is more useful than selecting whichever sentence supports the code already written.
A practical reference map
The button example leaves the developer with a small set of source types, each answering a different question:
- What does this native element mean and do?
- Consult the relevant HTML definition. Check attributes, behavior, authoring requirements, and the conditions that affect them.
- What accessibility requirements apply to the result?
- Consult the WCAG version used for the evaluation. Read the relevant criteria alongside the conformance requirements.
- Why does a criterion matter, and how should I interpret it?
- Use the corresponding Understanding document, keeping its explanatory role distinct from the criterion itself.
- How could I implement or evaluate a solution?
- Consult relevant WCAG Techniques and APG patterns. Check applicability, limitations, and support notes rather than treating an example as automatic proof.
- Does it work in the environments we support?
- Use implementation documentation and direct testing. Record the conditions under which the behavior was verified.
The developer can now explain the decision: HTML informed the native element choice; WCAG framed the accessibility review; supporting guidance clarified interaction expectations; implementation testing checked the finished behavior.
That is the durable habit behind standards literacy. Identify the question, find a source with the right scope, read its status, and distinguish what the document establishes from what the implementation still needs to demonstrate.