Giters

w3c / css-a11y

Main repository for the CSS Accessibility Task Force

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Stopping text from being exposed as one char/word per line (or making this condition easily identifiable)

joanmarie opened this issue · comments

commented

There are certain CSS techniques which can cause text to be exposed via accessibility APIs as if the content were one character per line.

I've not yet taken the time to pinpoint exactly what all can cause this. However, the most frequent time I see this is with off-screen text (e.g. on Amazon.com, but by no means limited to that). It can also be seen in the "Rated 4.7 out of 5" text found on https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/

If an assistive technology gets the text one character per line, it's in danger of only presenting a single character each time the user presses Down Arrow. That's super annoying for the user. As a result, screen readers need to detect this condition.

Currently, at least for my platform (ATK/AT-SPI2), there is no easy way to check for this condition (no property exposed; bounding box doesn't reliably indicate the problem). Thus what I've wound up doing is actually checking if the text in a given element is exposed in this broken fashion (by getting all of it line by line). Having to do this for every element, just in case it's broken (most elements are not), is unfortunate. Hence my filing this bug.

I can envision two solutions:

  1. Put in the CSS spec(s) statements telling user agents how to determine functional lines so text is not exposed as one char/word per line. This solution would NOT go into an AAM (imho) because it's not platform-specific mappings (which is what goes into AAMs).
  2. Figure out which CSS property(ies) cause this brokenness and then expose some platform-specific property via accessibility APIs to alert ATs that text correction will be needed. This solution WOULD go into an AAM rather than a spec (imho).

My preference is solution 1 because it's easier for me (a screen reader developer). 😄 But I'm totally good with solution 2. It would be easier and more performant to just ask for the hypothetical text-correction-needed property rather than to have to check the full text for broken exposure.