# XML Accessibility Guidelines

> Canonical HTML version: https://rocketvalidator.com/glossary/xml-accessibility-guidelines
> Attribution: Rocket Validator (https://rocketvalidator.com)
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

XML Accessibility Guidelines (XAG) is a W3C Working Group Note that provides techniques for ensuring XML document formats and applications are designed with accessibility in mind, complementing WCAG by addressing the creation of accessible XML-based languages and content.

XML Accessibility Guidelines, commonly abbreviated as XAG, is a set of recommendations published by the W3C's Protocols and Formats Working Group. While WCAG focuses on making web content accessible and ATAG addresses authoring tools, XAG targets a different layer: the design of XML-based formats themselves. The guidelines help language designers build accessibility support directly into new XML vocabularies, so that documents written in those formats can be made accessible from the start.

XAG 1.0 was published as a W3C Working Group Note in 2002. It is not a W3C Recommendation, but it has influenced how XML-derived languages (including XHTML, SVG, MathML, and SMIL) handle accessibility features. The guidelines describe what an XML format needs to provide so that authors using that format can produce content accessible to people with disabilities.

## Why XML Accessibility Guidelines matters

When someone designs a new XML vocabulary, the decisions made at the language level determine what authors can and cannot express. If a markup language lacks a mechanism for text alternatives, no amount of author effort can make images in that language accessible to screen reader users. XAG addresses this structural problem by requiring language designers to think about accessibility before a single document is ever authored.

The people most directly affected by XAG are specification authors, standards bodies, and developers building XML-based data formats. Indirectly, everyone who consumes content in those formats benefits. A language designed following XAG principles will have built-in support for things like alternative content, device independence, navigation structures, and styling separation.

Without these guidelines, XML language designers might omit features that are needed for accessibility. For example, early versions of some XML formats had no equivalent of HTML's `alt` attribute, making it impossible to provide text alternatives for embedded media. XAG exists to prevent that kind of gap.

## How XML Accessibility Guidelines works

XAG 1.0 is organized around four broad principles, each with specific guidelines and checkpoints.

### Ensure device independence

XML formats should not assume a particular input or output device. A language that only describes visual layout, with no semantic structure, forces content into a single modality. XAG calls for formats to separate content from presentation and to allow interaction through multiple devices (keyboard, pointer, voice, etc.).

### Ensure accessible content negotiation

The format should allow authors to provide equivalent alternatives for different types of content. This is the same concept behind the `alt` attribute in HTML or `<desc>` in SVG. XAG generalizes the principle: any XML language that includes non-text content should define a way to associate a text alternative with it.

### Provide accessible context and orientation

Navigation, structure, and relationships between elements should be expressible in the format. This means the language needs elements or attributes for headings, labels, grouping, and linking. Without these, assistive technologies cannot convey document structure to users.

### Ensure that the format is usable with accessible technologies

The format should be compatible with accessibility APIs and assistive technologies. This includes defining how elements map to accessible roles, states, and properties, much like the WAI-ARIA specification does for HTML.

## Relationship to HTML and WCAG

HTML itself was influenced by accessibility thinking that predates XAG, but several HTML-adjacent technologies show XAG's influence directly. SVG's `<title>` and `<desc>` elements, MathML's `alttext` attribute, and SMIL's accessibility features all align with XAG checkpoints. WAI-ARIA can also be seen as a practical realization of several XAG principles applied to HTML and SVG.

For web developers working with HTML, XAG is not something to conform to directly. Instead, it is useful context for understanding why HTML and its companion specifications include the accessibility features they do.

## Code examples

The following examples illustrate how XAG principles manifest in actual markup. Though XAG is about language design, the consequences are visible in the documents authors write.

A custom XML vocabulary that ignores XAG might define an image element with no provision for alternative text:

```xml
<!-- Bad: custom XML format with no text alternative mechanism -->
<picture src="chart-q3-revenue.png" width="600" height="400" />
```

There is no attribute or child element where an author could supply a description. A screen reader processing this format would have nothing to announce.

A format designed with XAG in mind would include a way to provide alternatives:

```xml
<!-- Good: custom XML format with built-in text alternative support -->
<picture src="chart-q3-revenue.png" width="600" height="400">
  <alt>Bar chart showing Q3 revenue: $4.2M in July, $3.8M in August, $5.1M in September.</alt>
</picture>
```

The same principle in HTML and SVG:

```html
<!-- Bad: SVG graphic with no accessible name -->
<svg width="100" height="100">
  <circle cx="50" cy="50" r="40" fill="green" />
</svg>
```

```html
<!-- Good: SVG graphic with title and desc for accessibility -->
<svg width="100" height="100" role="img" aria-labelledby="svg-title svg-desc">
  <title id="svg-title">Status indicator</title>
  <desc id="svg-desc">Green circle indicating the service is online.</desc>
  <circle cx="50" cy="50" r="40" fill="green" />
</svg>
```

The `<title>` and `<desc>` elements in SVG exist because SVG was designed with XAG-style thinking. They give authors a way to provide text alternatives, and `aria-labelledby` connects them to the accessible name computation that assistive technologies rely on.

```html
<!-- Bad: custom data displayed without semantic structure -->
<div class="report">
  <div class="big-text">Quarterly Summary</div>
  <div>Revenue increased across all regions.</div>
</div>
```

```html
<!-- Good: semantic structure enabling accessible context -->
<article>
  <h2>Quarterly Summary</h2>
  <p>Revenue increased across all regions.</p>
</article>
```

XAG's guideline on context and orientation is the reason HTML provides elements like `<article>`, `<h2>`, and `<nav>`. These structural elements let assistive technologies present document organization to users who cannot see visual formatting cues.

## XAG in current practice

XAG 1.0 has not been updated since 2002, and the W3C has not advanced it to Recommendation status. Its principles, however, live on in WCAG 2.x, WAI-ARIA, and the accessibility features of modern web standards. Developers building new XML-based formats or extending existing ones will find XAG a useful checklist for ensuring their language does not create accessibility barriers that downstream authors cannot fix.

===