_Alt-text as poetry_ is a project by Bojana Coklyat and Shannon Finnegan:
_Alt-text as poetry_ is a project by Bojana Coklyat and Shannon Finnegan:
a workbook dedicated to the alternative text descriptions that make web images accessible to people who are blind, with a low vision condition, or have other cognitive disabilities.
a workbook dedicated to the alternative text descriptions that make web images accessible to people who are blind, with a low vision condition, or have other cognitive disabilities.
Websites are made of HTML, a markup language composed of tags. Each tag represents an element of the document: a header, a paragraph, a link to another page, an image, and so on. As in a sandwich, these tags can be composed together, and organized to structure the contents of a web page. Every tag presents particular attributes, and the image `<img>` one requires the developer to specify the source `src` of the picture to display. Here is also possible, but not technically mandatory, to add an `alt` attribute, with the alternative description of the image used by screen readers and other assistive technologies.
Websites are made of HTML, a markup language composed of tags. Each tag represents an element of the document: a header, a paragraph, a link to another page, an image, and so on. As in a sandwich, these tags can be composed together, and organized to structure the contents of a web page. Every tag comes with particular attributes, and the image `<img>` one requires the developer to specify the source `src` of the picture to display. Here is also possible, but not technically mandatory, to add an `alt` attribute, with the alternative description of the image used by screen readers and other assistive technologies.
@ -157,21 +157,11 @@ Websites are made of HTML, a markup language composed of tags. Each tag represen
Alt-text is an essential part of web accessibility. It has existed since the 1990s, but it is often disregarded or understood through the lens of compliance, as an unwelcome burden to be met with minimum effort. By design, the HTML specifications treat it as optional. While omitting the source `src` of a picture precludes the display of the image, the same is not true for the absence of an `alt` text.
Alt-text is an essential part of web accessibility. It has existed since the 1990s, but it is often disregarded or understood through the lens of compliance, as an unwelcome burden to be met with minimum effort. By design, the HTML specifications treat it as optional. While omitting the source `src` of a picture precludes the display of the image, the same is not true for the absence of an `alt` text.
The workbook of Cocklyat and Finnegan is a whole piece of code documentation dedicated to a single HTML attribute. It re-frames `alt` text as a type of poetry, and provides exercises to practice writing. Their intention is not just to allow alt-text users to be able to access visual content on the internet, but to let them feel a sense of belonging in the digital spaces.
The workbook of Cocklyat and Finnegan is a whole piece of code documentation dedicated to a single HTML attribute. It re-frames `alt` text as a type of poetry, and provides exercises to practice writing. Their intention is not just to allow alt-text users to be able to access visual content on the internet, but to let them feel a sense of belonging in the digital spaces. By highlighting the needs of often marginalized minorities, and giving them propper representation, documentation can activate ways of thinking that actively shape technical implementations, acknowledging both the needs of machines and programmers and users as well.
By highlighting the needs of marginalized minorities, and giving them propper representation, the documentation can activate ways of thinking to shape technical specification, caring for the needs of programmers and users as well as underlying machines.
The `p5.js` library for example offers a `describe()` and `describeElement()` functions, to provide a description analogue to the `alt` text one for their visual sketches. The interactive graphics are based on the HTML `canvas` element, that instead of dealing with its contents in a semantic way as HTML does, works on pixel bases. Similar to images, these contents are not compatible with screen readers, and require a text explanation in order to render accessible what's happening on screen. Even more: while images are usually static, p5.js visuals are often in motion, and evolve through time. With `describeElement()`, developers can even be more granular in their descriptions, captioning transformations of different elements in their animations.
---
In the discussions on GitHub around the development of this open source project, contributors started considering how to encourage the usage of this function. From an initial suggestion of making it required in order to run the sketch, opinions settled on conveying its importance from the pages in the documentation, by adding it to the default in sketches templates, and to the examples in the documentation. (Actually, not happened yet. But there are pull requests with some of these integrations awaiting to be merged with the main branch.) `(ok rephrase it not to write pull request and merge)`
in the discussions around the development of p5.js once i read an interesting thread about having in every script a mandatory `describeElement()` function offering a text description of the running sketch (so are called p5.js scripts). p5js graphics are based on the html canvas element, that instead of organizing its contents in more or less semantic way as html does, presents only a matrices of pixels. this is a big hustle for screen readers and accessibility. the `describeElement()` function is the same as the one of alt attribute, describing what's happening on screen.
the interesting part of the discussion was about this function to be mandatory in order to make the script run
and it is interesting to think how it would be reflected in the library documentation:
to which kinds of world would a choice like that openn?
not relegating them to the background, but instead making them as important as all the other (technical) choices that were made when desining the language
as for now it's not happened. open source projects like this one are collective effort, and to take big decisions with breaking changes like this one is always complex and slow
