Hi
On 4/5/24 20:01, Juliette Reinders Folmer wrote:
In the "It decreases readability" section you make a sweeping statement
about accessibility, but don't back that up with research. Please back
your statement up as based on my understanding, the opposite is true.
For context: This paragraph was added by Larry. It's my name on the RFC
of course and I approved of the addition he made. Nevertheless Larry
might've additional resources to add here.
Case in point: if written in all caps, screenreaders will spell the
characters out - think HTML -. If written in Mixed case, screenreaders
will try to pronounce the word, making acronyms and other abbreviations
very hard to understand for anyone using a screenreader.
This is something which has repeatedly been pointed out, for instance at
conferences regarding conference acronym hashtags, like #DPC.
So, I'd be very interested to see your statement backed up by actual
research and invite you to look into this a little deeper.
Your remark looks at the accessibility from the PoV of a developer with
impaired eyesight that is dependent on assistive technology. However
accessibility also affects developers with regular vision. The concerns
of these two groups might conflict.
W3C's accessibility guidelines point out that:
> Text in all capital letters is more difficult to read for most
people, with and without disabilities.
(https://w3c.github.io/low-vision-a11y-tf/requirements.html#capitalization)
Harvards's Accessibility Guidelines agree:
> Avoid using all caps. Readability is reduced with all caps because
all words have a uniform rectangular shape, meaning readers can't
identify words by their shape.
(https://accessibility.huit.harvard.edu/design-readability)
Of course program identifiers are not regular text and indeed more
similar to hashtags, in that they do not permit the inclusion of
whitespace to separate words. Underscores would work, but that would
just add to the inconsistency.
For Hashtags I found several resources pointing out to capitalize each
word separately. For acronyms most resources pointed out that they
should be avoided entirely (e.g.
https://studentlife.mit.edu/das/accessibility/digital-accessibility/socialmedia,
https://www.nyu.edu/life/information-technology/web-and-digital-publishing/digital-publishing/accessibility/how-to-guides/social-media.html#acronyms)
and that recommendation is already part of the existing guidelines.
I've tested with my Android phone with the 'performHttpRequest' example
and both variants where read out equally terrible as 'per-form age tee
tee pre-quest' (i.e. merging the p with the request). And your example
of HTML was read out as 'age tee em el' (or rather the German
pronounciation of the letters) for both HTML and Html. The lack of
vowels might've helped with the result, though.
The case of the boundary between two consecutive acronyms being unclear
should affect developers with regular vision and impaired vision alike
(i.e. PDOODBC and XSLRR).
From my personal experience as a human with regular vision (not even
glasses), the variant of treating acronyms as regular words is much
easier to parse.
Best regards
Tim Düsterhus
