search

w3c / html-aam

HTML Accessibility API Mappings - new spec updates should be made in https://github.com/w3c/aria/tree/main/html-aam
https://w3c.github.io/html-aam/
Other
100 stars 26 forks source link

Proposal: HTML use of remote alt text; matching extension/formalization for HTTP Content-Disposition & MIME #309

Open saizai opened 3 years ago

saizai commented 3 years ago

Recipient list

WHATWG: html, html-aam, html-aria W3C WGs: html, apa, aria, webapps IETF WGs: httpbis, 822ext

CC authors of (current) prior RFCs: Nathaniel Borenstein, Steve Dorner, Ned Freed, Ed Levinson, Keith Moore, Julian Reschke, Rens Troost

Cross-posted by email to W3C & IETF groups, and by GitHub to WHATWG at:

The content is equivalent, modulo small formatting changes for Markdown vs email, and addition of section deeplinks in Markdown version.

Background

Objective

Humans with disabilities, and machines, should have fully equal access to the textual content of image and other files.

Problems with the current specs

  1. In current practice, the embedder of content often fails to add alt tags, making it inaccessible to people with disabilities and to computers.
  2. It is literally impossible for the embedder to describe some content, e.g. dynamic images; in such situations, the current specs cannot fulfill the goal of accessibility.
  3. An image's embedders must describe its content, even though its source is better able to do so, both practically and authoritatively.
  4. Human effort is wasted by requiring many end users to write content descriptions for a single source file.
  5. Updates to the HTTP Content-Disposition header spec failed to include Content-Description in the spec.
  6. MIME/HTTP Content-Description is equivalent to HTML LONGDESC (narrative description). There's no current field equivalent to ALT (verbatim content in text form).

Relevant prior RFCs

HTTP/1.1 Content-Disposition header & Content-Description field

HTML

MIME Content-Description header

EXIF

Discussion

  1. In current practice, the image's source server will often have all the necessary metadata to describe the image.

It could put this metadata in its HTTP headers. However, this information is either not transmitted, or not used.

Some image formats provide for the necessary metadata. However, these are rarely used — typically, it's stored separately — and not all image formats have this support.

  1. Some images used in HTML are deliberately dynamic.

Consider the various dependency/test status images used on GitHub.

Only the remote image server knows, at display time, what the image represents. This is because it runs test suites on the most recent version of the codebase, checks the current status of servers, monitors third-party published vulnerabilities or library updates, etc.

Example: https://github.com/atom/atom

The first 3 images in the README section are: a. Azure Pipelines build/test/integration status b. David Dependency Manager dependencies update status c. Heroku/Slack server status [this image currently doesn't load]

The correct alt text for these, at time of writing, should be: a. Azure Pipelines succeeded b. dependencies up to date c. Heroku is offline for maintenance

It's impossible for the author of README.md, or GitHub itself, to know any of this before the user agent actually fetches the image.

As a result, people using a screen reader get zero information from these images, whereas sighted users know the live statuses .

(Pedantic caveat: actually, GitHub runs a caching proxy server on such images; they aren't fetched by the user agent directly from the authoritative server. However, this is functionally transparent.)

  1. Content-Description is not defined equivalently to ALT text.

Content-Description is defined as "some descriptive information" (RFC 2045 § 8). All examples in the RFCs are either narrative, e.g. "just a small picture of me" (RFC 2183 § 3), or useless, e.g. "jpeg-1" (id.).

By contrast, ALT text is meant to be the nearest equivalent — which, in the case of simple images of short text, is the verbatim text.

HTML 4.01 (§ 13.8) describes it as "alternate text to serve as content when the element cannot be rendered normally".

HTML 5 describes it as "equivalent content for those who cannot process images or who have image loading disabled (i.e. it is the img element's fallback content)" (§ 4.8.3). It "should never contain text that could be considered the image's caption, title, or legend. It is supposed to contain replacement text that could be used by users instead of the image; it is not meant to supplement the image" (§ 4.8.4.4.1).

AFAICT, there is no equivalent field in either HTTP or MIME. There could and should be.

Proposals

Mime — Content-Text

Update RFC 2045 to add the header Content-Text, defined as follows.

Content-Text should contain that text, following the specifications in WHATWG HTML 5 § 4.8.4.4.

All files should include this header if:

  1. the file is not a TXT/* MIME type, and
  2. the file semantically (if not digitally) a. contains text, or b. has a text equivalent

HTTP — Content-Disposition

Update RFC 2183 and RFC 6266 to change the Content-Disposition header as follows:

  1. formalization of Content-Description Re-add the Content-Description field, as defined in RFC 1521 § 6.2.
  2. addition of Content-Text Add the field Content-Text, defined identically to the RFC 2045 update above, by reference.

HTML-AAM — IMG and INPUT type=image

Insert the following before the "none of the above" option in the HTML-AAM accessible name computation instructions:

When an ALT or TITLE attribute is not available, use the first available of the following:

  1. equivalent metadata in the image file, e.g. the Exif.Image.ImageDescription field
  2. image's HTTP Content-Disposition header's Content-Text field
  3. image's HTTP Content-Disposition header's Content-Description field

HTML — no change

There is deliberately no change proposed to the HTML spec itself.

The purpose of this proposal is to address situations where the HTML author does not, or cannot, add the relevant information. Therefore, the changes are to user agent behavior, and to the data accessible to user agents from sources other than the HTML, i.e. server and file headers.

Intellectual property release

All original IP in this proposal is owned jointly by Sai and Fiat Fiendum.

We freely license it as follows:

  1. Copyright: CC-by (attribution-only)
  2. Patentable material: public domain where possible, otherwise CC Public Patent License

Sincerely, Sai President, Fiat Fiendum, Inc., a 501(c)(3)

PS Non-gendered pronouns please. I'm a US citizen.

saizai commented 3 years ago

Content-Text should contain that text, following the specifications in WHATWG HTML 5 § 4.8.4.4.

Editing fail. "That" refers to the immediately following "if" block.

lrosenthol commented 3 years ago

This should also be connected with https://github.com/whatwg/html/issues/5890 which proposes to enable access to XMP (the standard for embedded asset metadata) by browsers/. It evens mentions previously efforts by the W3C to address the problem.

saizai commented 3 years ago

@lrosenthol Thanks for the cross link. I wasn't aware of XMP. Seems like a very good overlap, and https://www.w3.org/html/wg/wiki/Metadata specifically mentions the accessibility use case.

saizai commented 3 years ago

@dwsinger wrote on the w3c email thread:

You should probably be aware that we recently amended the base HEIF format (which is not tied to HEVC, and indeed lays under AVIF) to allow for intrinsic alt text(s) (possibly plural in multiple languages), as this enables the image creator to make that text at the time of file creation, and for it to travel automatically with the image.

mnot commented 2 years ago

Just for clarity -- HTTP does not use MIME, so updating those specs won't have any effect, and isn't necessary. All you need is a small spec defining a brand new HTTP header field. And, of course, people to implement it.

If you want to do that in the HTTP Working Group it should be easy to get it going. If not, please loop folks there in on reviews. For example, it's probably a good idea to make it a structured field since it's new, and you should look through this text too.

dwsinger commented 2 years ago

I think that people still use the old name (MIMEtype) for things that are now called mediatypes…but ok