Html: Consider specifying heuristics for when <ul> represents a list

Created on 11 Dec 2020  Â·  9Comments  Â·  Source: whatwg/html

See https://twitter.com/cookiecrook/status/1337226933822603270 and https://bugs.webkit.org/show_bug.cgi?id=134187

Do other browser engines do this for ul? If not, are users complaining about it? Is there interest in aligning with WebKit?

The HTML spec currently suggests (non-normatively) some heuristics for table:

User agents, especially those that do table analysis on arbitrary content, are encouraged to find heuristics to determine which tables actually contain data and which are merely being used for layout. This specification does not define a precise heuristic, but the following are suggested as possible indicators:

https://html.spec.whatwg.org/multipage/tables.html#the-table-element

cc @whatwg/a11y

a11y-tracker accessibility

Most helpful comment

I think it is worth considering stripping the tables guidance from the HTML specification instead.

Currently screen readers are the ones applying heuristics to tables, not the User Agent — barring documented bugs in the mis-application of display properties, that is.

The tables guidance, and discussion around list guidance, would move to the AAM following @stevefaulkner's suggestion:

AFAIK no other browsers modify the accessibility tree for UL/LI based on heuristics, would it not be better to put this into the HTML acc API spec as it is concerning the exposure of role information in the acc tree?

All 9 comments

AFAIK no other browsers modify the accessibility tree for UL/LI based on heuristics, would it not be better to put this into the HTML acc API spec as it is concerning the exposure of role information in the acc tree?

There does appear to be a difference in how screen readers expose lists to users based on whether list-style-type:none is set

The removal of semantic information based on the presence of a visual design property does not seem like a good thing.

A list is still a list whether it has a visible bullet marker or not. If it isn't, then it should not be presented using list markup.

@LJWatson indeed, but reality doesn't always match up with ideals. The same can be said about table, yet everyone uses heuristics to detect layout tables because otherwise the web is unusable. WebKit made a similar call for ul based on complaints from VoiceOver users.

I would say the more sustainable option would have been to make it a setting in VoiceOver or whatever "don't announce styled lists" (combined with setting a flag of sorts in the browser when it exposes to accessibility tree - a la "this is a list, but it MAY be used in a non-list fashion")

Ignoring author-specified markup under the "they always get it wrong anyway" pretext seems...not ideal.

This almost has a whiff of doctype switching to it ... where authors had to use the doctype to assure the browser that yes, they in fact knew what they were doing...

I think it is worth considering stripping the tables guidance from the HTML specification instead.

Currently screen readers are the ones applying heuristics to tables, not the User Agent — barring documented bugs in the mis-application of display properties, that is.

The tables guidance, and discussion around list guidance, would move to the AAM following @stevefaulkner's suggestion:

AFAIK no other browsers modify the accessibility tree for UL/LI based on heuristics, would it not be better to put this into the HTML acc API spec as it is concerning the exposure of role information in the acc tree?

I posted this comment via email about an hour ago and it seems to have been lost somewhere en route. Apologies if it turns up again in due course.

The same can be said about table, yet everyone uses heuristics to detect layout tables because
otherwise the web is unusable.

Indeed. I am not convinced that a list without its visual bullet markers qualifies as unusable though. Certainly not as unusable as content intended to
be a list that is heuristically determined not to be a list based on the absence of a visual bullet marker.

On Windows and Linux, we merely provide a hint to assistive technologies via an object attribute if we think we found a layout table. Only on MacOS do we modify the exposed tree based on that determination, to match WebKit behavior. If we implement this for lists, we would take a similar approach: provide the hint on Windows and Linux, but let ATs decide what to do with it, but only modify the tree in the Mac layer based on that info.

Here is the relevant Firefox Bug.

Was this page helpful?
0 / 5 - 0 ratings