Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Pointer input" definition has broken reference in understanding documents #2535

Open
patrickhlauke opened this issue Jul 2, 2022 · 5 comments · May be fixed by #4174
Open

"Pointer input" definition has broken reference in understanding documents #2535

patrickhlauke opened this issue Jul 2, 2022 · 5 comments · May be fixed by #4174
Assignees

Comments

@patrickhlauke
Copy link
Member

If you look at https://w3c.github.io/wcag/understanding/target-size-minimum.html#key-terms, note how the end of the "Pointer input" key term definition has an unprocessed [[!pointerevents]] at the end.

In the main WCAG document, this is correctly processed to a bibliography link - see https://w3c.github.io/wcag/guidelines/22/#dfn-pointer-inputs

@alastc
Copy link
Contributor

alastc commented Aug 12, 2022

We had a look at this, the same happens for the CSS pixel definition: https://w3c.github.io/wcag/understanding/target-size-enhanced.html#dfn-css-pixel

Looks like the template/generator doesn't do it's job in the understanding doc?

@kfranqueiro
Copy link
Contributor

There's also a whole litany of references in Contrast (minimum), which is particularly interesting because they appear under Intent which is strictly part of the informative docs (as opposed to the term definitions which originate under guidelines/). To be clear, neither the XSLT nor Eleventy build systems for techniques/understanding ever supported references within the informative docs. (These appear unprocessed even in the 2.0 publication.)

Resolving this will require implementing the equivalent of ReSpec's bibliography functionality within the build process for techniques/understanding, which I presume means we'd need to generate a Bibliography section similar to how we generate Key Terms. It also necessitates scanning text in all definitions + all p elements in understanding/* files, which might noticeably impact build times.

@iadawn
Copy link
Contributor

iadawn commented Sep 12, 2024

I am not sure that we need a "bibliography" section in the same way as is in REC documents. I think adding in the link would be sufficient.

@kfranqueiro
Copy link
Contributor

I'm posting an update here after closing out other issues referencing the same root cause.

We have several of these bibliographical references in various states of resolvability:

  • Those that are resolvable to URLs using this repo's biblio.js
  • Those that are resolvable to URLs via information at specref.org (which has an API we can easily query)
  • Those that do not have a mapping in either of those sources: LAALS, HEARING-AID-INT, ISO-9241-3, ANSI-HFES-100-1988, ARDITI-FAYE, ARDITI-KNOBLAUCH-1994, ARDITI-KNOBLAUCH-1996, ARDITI, GITTINGS-FOZARD
    • This encompasses most of the instances under understanding (vs. under guidelines)
    • These are cited in various files under wcag20; most notably, all of them seem to be present in guide-to-wcag2-src.xml. However, the XML bibliographies under wcag20 do not have URLs, which is really what we'd like to use within the Understanding documents. These were only ever present in local bibliographies within the same document, and I am under the impression they only ever worked within the TR version of Understanding Docs for 2.0.

I have a solution for the first two buckets. Regarding the third, I'm not sure if it's feasible to fish up approrpriate URLs for them.

kfranqueiro added a commit that referenced this issue Nov 20, 2024
Refs #2535

This adds support to the Eleventy build system for resolving
bibliographical references within paragraphs in the format `[[ref]]`,
and converting them into links within single brackets instead.

This resolves against both specref.org and the local bibliography
configured in `biblio.js` in this repo.

Note that there are some references that have no resolution in either of
these sources, which is why I'm not marking this as fully resolving the
related issue.

Details at
#2535 (comment)
@alastc
Copy link
Contributor

alastc commented Dec 9, 2024

In the 3rd bucket, I think these affect background-audio and contrast. Could we just use the references and add those as text to the resources section?

@kfranqueiro kfranqueiro linked a pull request Dec 12, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants