Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122987
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-333-gbfea15422e-fm-20240327.001-gbfea1542
Precedence: bulk
MIME-Version: 1.0
Message-ID: <37f1b0c6-a7c8-41f3-bf2f-7dd466bb31c9@app.fastmail.com>
In-Reply-To: <80ac7108-e016-4ae8-87ad-50afa0c2f257@bastelstu.be>
References: <792b2282-b7a3-40dd-899c-daab55353316@bastelstu.be>
 <69107662-eb03-4b75-8eed-59dd2eed6559@gmail.com>
 <66103C7A.3040906@adviesenzo.nl>
 <80ac7108-e016-4ae8-87ad-50afa0c2f257@bastelstu.be>
Date: Fri, 05 Apr 2024 20:55:10 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Apr 5, 2024, at 7:15 PM, Tim D=C3=BCsterhus wrote:
> Hi
>
> On 4/5/24 20:01, Juliette Reinders Folmer wrote:
>> In the "It decreases readability" section you make a sweeping stateme=
nt
>> 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 RF=
C=20
> of course and I approved of the addition he made. Nevertheless Larry=20
> 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 abbreviatio=
ns
>> very hard to understand for anyone using a screenreader.
>>=20
>> This is something which has repeatedly been pointed out, for instance=
 at
>> conferences regarding conference acronym hashtags, like #DPC.
>>=20
>> 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 wit=
h=20
> impaired eyesight that is dependent on assistive technology. However=20
> accessibility also affects developers with regular vision. The concern=
s=20
> 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=20
> people, with and without disabilities.
>
> (https://w3c.github.io/low-vision-a11y-tf/requirements.html#capitaliza=
tion)
>
> Harvards's Accessibility Guidelines agree:
>
>  > Avoid using all caps. Readability is reduced with all caps because=20
> all words have a uniform rectangular shape, meaning readers can't=20
> identify words by their shape.
>
> (https://accessibility.huit.harvard.edu/design-readability)
>
> Of course program identifiers are not regular text and indeed more=20
> similar to hashtags, in that they do not permit the inclusion of=20
> whitespace to separate words. Underscores would work, but that would=20
> just add to the inconsistency.
>
> For Hashtags I found several resources pointing out to capitalize each=20
> word separately. For acronyms most resources pointed out that they=20
> should be avoided entirely (e.g.=20
> https://studentlife.mit.edu/das/accessibility/digital-accessibility/so=
cialmedia,=20
> https://www.nyu.edu/life/information-technology/web-and-digital-publis=
hing/digital-publishing/accessibility/how-to-guides/social-media.html#ac=
ronyms)=20
> and that recommendation is already part of the existing guidelines.
>
> I've tested with my Android phone with the 'performHttpRequest' exampl=
e=20
> and both variants where read out equally terrible as 'per-form age tee=20
> tee pre-quest' (i.e. merging the p with the request). And your example=20
> of HTML was read out as 'age tee em el' (or rather the German=20
> pronounciation of the letters) for both HTML and Html. The lack of=20
> vowels might've helped with the result, though.
>
> The case of the boundary between two consecutive acronyms being unclea=
r=20
> should affect developers with regular vision and impaired vision alike=20
> (i.e. PDOODBC and XSLRR).
>
>  From my personal experience as a human with regular vision (not even=20
> glasses), the variant of treating acronyms as regular words is much=20
> easier to parse.
>
> Best regards
> Tim D=C3=BCsterhus

Thanks Tim.  Those are the same resources I was going to cite. :-)  I'll=
 also add

From the APA: https://apastyle.apa.org/style-grammar-guidelines/paper-fo=
rmat/accessibility/typography

"It is true that presenting text in all caps will slow down all readers,=
 especially those with certain types of visual and/or cognitive impairme=
nts."

(They then go on to recommend using proper casing in the source and CSS =
styles to capitalize things, so that screen readers ignore it, which see=
ms dumb to me given the other resources cited above.)

And from the a11y Project: https://www.a11yproject.com/posts/how-to-acce=
ssible-heading-structure/#all-caps

"Text in all capitals is harder to read. The shape of a word disappears,=
 every word becomes a rectangle. Research shows that all caps text is es=
pecially difficult for readers with dyslexia. Make life easy for your re=
aders, don't capitalize all the words."

So the professional consensus among accessibility and publishing organiz=
ations is absolutely that ALLCAPS is bad for readability and accessibili=
ty.

I've added some of the links above to the RFC for citation.

--Larry Garfield