Open fstrr opened 5 months ago
To add this here, too:
E.g., 196 cases of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>
for a document of this size (currently printing to over 300 pages) does not seem too large to me.
It would be good for the group to decide on a particular style here. But I tend to prefer not to change things for change's sake.
I've edited my comment above to add the WAI-ARIA example that was lost in moving to the issue tracker.
Even with 700, I don't see it as such a huge problem. But clear guidelines (e.g., once per section) seem very sensible (in particular in the introduction).
per the call today, i agree that there are a lot of unnecessary instances of abbrs with titles. but some of those might be helpful, and also i'm not sure it makes sense to remove the abbr elements all together.
can talk about that more in the editor's meeting though
Discussed briefly in triage at today's meeting: https://www.w3.org/2024/02/01-aria-minutes.html#t01
We discussed the issue in this week's editors meeting https://www.w3.org/2024/02/05-aria-editors-minutes.html#x005
There was a preference (among those present) to leave things as is for now. There was concern about consistency both within ARIA specs as well as with regards to other (W3C) specs.
See #2136 for a renewed effort.
Devtools suggests there are over 700
abbr
elements in the current 1.2 spec. Recent research shows that these have little-to-no benefit to the user, with most assistive technology ignoring the element. Some assistive technology does announce the contents of theabbr
element's title attribute, which then, with so many elements on the page, creates a very verbose-sounding document.The best practice for expanding abbreviations is to expand them in text the first time they are used in a document. For example: "BBC (British Broadcasting Corporation)".
This PR removes all the
abbr
elements I could find and expands each abbreviation the first time I found it on the page.I was looking at the current 1.3 Editor's Draft.