3 ms·

Not to be too negative, but this seems quite inaccessible to anyone using a screen reader or other non-visual output device. Unlike with SVGs or images, there s

by rmccue 3y ago

Not to be too negative, but this seems quite inaccessible to anyone using a screen reader or other non-visual output device. Unlike with SVGs or images, there seems to be no way to provide an alternative representation? Similar to the inaccessibility of icon fonts, but those tend to use private use character codes rather than actual readable text; reading the example page [1] with a screen reader is... not a great experience. [1]: https://dy.github.io/linefont/scripts/ https://dy.github.io/linefont/scripts/

petee 3y ago
Are there any other html attributes that could hint to a screenreader what to read or ignore? I can think of more than a few examples when plaintext in a page really should be provided an 'alt' equivalent, if not outright ignored (eg., ascii art, binary strings, etc)
- myfonj 3y ago
  Yes, "alt" equivalent for "textual data representation" is ARIA role="img" with aria-label [0]: <span role="img" aria-label="[what assistive technologies should present]">[rendered content]</span> e.g. recommended for marking up obscure emoji [1]. Anyways, I see absolutely no reason why these projects (wavefont and linefont) build on top of plain ASCII (so the actual data sound as garbled nonsense) and not ligatures of actual figures, so what they "encode" as abz could easily be something represented like, for example :1 :2 :26 or any other human-readable sequence of characters what would match defined ligatures in the font, or be presented verbatim if the font failed to load/work. [0] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/img_role#using_roleimg_to_confer_meaning_that_is_obscured_or_implied https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [1] https://adrianroselli.com/2016/12/accessible-emoji-tweaked.html https://adrianroselli.com/2016/12/accessible-emoji-tweaked.h...
  - dy108 3y ago
    The reason for textual range is maintaining textual selection / editing interactions and 1:1 character<->value matching, so by deleting one character you delete one value. It is almost same as your suggested representation, just do `String.fromCharCode(values.map(v => v + 0x100))` or manually as `&#x1XX;&#x1XX;&#x1XX;` in HTML.

by rmccue 3y ago

petee 3y ago

Are there any other html attributes that could hint to a screenreader what to read or ignore? I can think of more than a few examples when plaintext in a page really should be provided an 'alt' equivalent, if not outright ignored (eg., ascii art, binary strings, etc)

myfonj 3y ago
Yes, "alt" equivalent for "textual data representation" is ARIA role="img" with aria-label [0]: <span role="img" aria-label="[what assistive technologies should present]">[rendered content]</span> e.g. recommended for marking up obscure emoji [1]. Anyways, I see absolutely no reason why these projects (wavefont and linefont) build on top of plain ASCII (so the actual data sound as garbled nonsense) and not ligatures of actual figures, so what they "encode" as abz could easily be something represented like, for example :1 :2 :26 or any other human-readable sequence of characters what would match defined ligatures in the font, or be presented verbatim if the font failed to load/work. [0] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/img_role#using_roleimg_to_confer_meaning_that_is_obscured_or_implied https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [1] https://adrianroselli.com/2016/12/accessible-emoji-tweaked.html https://adrianroselli.com/2016/12/accessible-emoji-tweaked.h...
- dy108 3y ago
  The reason for textual range is maintaining textual selection / editing interactions and 1:1 character<->value matching, so by deleting one character you delete one value. It is almost same as your suggested representation, just do `String.fromCharCode(values.map(v => v + 0x100))` or manually as `&#x1XX;&#x1XX;&#x1XX;` in HTML.