search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.09k stars 242 forks source link

Some definition links (#dfn-*) point to fully-qualified URLs #3920

Closed kfranqueiro closed 1 month ago

kfranqueiro commented 2 months ago

Most definition links are in the format <a>term</a>, intended to be automatically resolved by the build process as indicated in the main README. These are responsible for populating each page's Key Terms section.

However, there are a handful of pages that contain links already pointing directly to TR URLs. For example, both ARIA22 and F103 have links pointing to /TR/WCAG/#dfn-status-messages, when instead they could be expressed as <a>status message</a> (either singular or plural), which would automatically expand and populate the term under Key Terms (using guidelines/terms/21/status-message.html).

I'm unsure if any of these instances are intentionally this way, but some of these links point to specific TR versions (i.e. we end up with some links from 2.2 informative docs to 2.1 normative content), and some even point to github.io URLs.

A search for /#dfn across the techniques and understanding directories should surface these instances.

patrickhlauke commented 2 months ago

how do we handle the few cases where the link text is slightly different from the actual term? for instance, <a href="/TR/WCAG/#dfn-web-page-s">web pages</a> or <a href="/TR/WCAG/#dfn-conforming-alternate-versions">conforming alternate version</a>?

kfranqueiro commented 2 months ago

how do we handle the few cases where the link text is slightly different from the actual term? for instance, <a href="/TR/WCAG/#dfn-web-page-s">web pages</a> or <a href="/TR/WCAG/#dfn-conforming-alternate-versions">conforming alternate version</a>?

This is handled via alternate term names in data-lt attributes in the individual term files. See Definitions in the README for explanation. (e.g. the two examples you mentioned are already handled.)