
Achieving Accessibility Through Simplicity - freddyym
https://sourcehut.org/blog/2020-05-27-accessibility-through-simplicity/
======
Nicksil
This article hit on a number of issues I have with today's Web development.

The Biggie:

>Remember that the browser is the user agent, not the developer agent.

Others I find significant:

>“trust the web browser”.

>Don’t mess about with the scroll wheel

>don’t override default behaviors on the right click and text selection.

>Don’t use JavaScript to create custom input elements like text boxes, combo
boxes, or scrollbars.

>Try not to use a purely visual representation of information, such as an
icon: these should always be paired with text.

>Also avoid moving information around — animations and visually complex state
transitions.

>When adding images, always include an “alt” tag with a plain-English
description of the image.

When using correct document structure and semantics, it can be amazing what
you get for "free" with respect to usability.

Additional issues I deal with on a daily basis which exist because some folks
weren't satisfied with the default, correct behavior:

\- A div with a "click" event is not a button or link

\- A div with nested span elements is not a select

\- The ad hoc "click" event handling does not handle auxiliary/middle click
behavior

\- An icon, with no accompanying text, also has no title attribute or anything
else to convey its purpose to the user

\- The ad hoc navigation implementation does not recall scroll position

\- The ad hoc navigation implementation does not allow me to "back" out of the
website

\- The scroll event handler, called tens/hundreds of times per second, so that
it can update the sticky "progress" bar that someone thought was necessary to
inform me how far along the article I've come, increases my energy bill and
the ambient temperature inside my home

Sometimes I just want to grab these folks by the collar and yell "Stop
touching it!"

~~~
esperent
I would append 'unless you do it really well' to a lot of these statements. In
fact, I bet you use websites on a daily basis that do many of these, but you
don't even notice because they do it well. You only notice those who do it
badly.

Except for stealing the back button. There's a special hell for any dev who
does that.

~~~
mwcampbell
The problem is that you can do it well enough that no one using a browser in
the normal way would notice, but people doing things differently, whether by
necessity (e.g. because of a disability) or preference, would still notice.

------
zomglings
One thing stood out to me, from reading the post and the HN discussion. I
think there's a real distinction to be made between web pages and web
applications. HN seems to have a bias against web applications which is
probably unfair.

Most web developers today do not set out to build web pages. They start with
full-on experiences they would like to bring to users, and the web stack is
their tool of choice in doing so. There is nothing wrong with this! And
different considerations apply in the development of such applications versus
a web page.

Philosophically, SourceHut is about non-browser-based workflows (e.g. using
email for merge requests). Since SourceHut users do far less of their
SourceHut-related work on the actual website, SourceHut can afford to take a
web page approach. GitHub, in contrast, focuses on browser-based workflows.
They actually do a pretty great job at it - and this is something that they
can do only because they take a web application approach. I like their
keyboard shortcuts, for example, but these would be difficult (impossible?) to
implement on a simple HTML page.

No single user can say that one approach is right and the other is wrong. All
they can do is assert preferences. At the end of the day, traffic does the
talking.

But thinking in terms of web pages vs. web applications makes things like
this:

> Many companies have written checks with an uncomfortable number of zeroes on
> them to get the job done.

more understandable.

~~~
Karrot_Kream
> HN seems to have a bias against web applications which is probably unfair.

It may be unfair, but I think part of it is a pushback against the cultural
zeitgeist that the web is meant as a platform to deliver content to passive
users. If web authors assume that users are out there to just passively
consume content, then yes most of the web will just be elaborately designed
applications designed to guide the passive user.

> All they can do is assert preferences. At the end of the day, traffic does
> the talking.

I think this simplification is part of the problem. Traffic doesn't dictate
anything. Just because The Bachelor receives more eyeballs than War and Peace
doesn't mean that The Bachelor is a superior product to War and Peace, or
conversely that War and Peace is a better product than The Bachelor. Each has
its place in our species' cultural milieu. The web has a growing culture of
trying to erase media plurality and embrace a single hot, or dominant form of
publishing, and I think this specifically leads to the outgrowth of these
sorts of big flamewars. Different forms of media can coexist, and traffic
isn't the only mark of success.

~~~
zomglings
Your reply really made me think - you are absolutely correct about traffic not
being the end all and be all measure of successful content. Thank you for
pulling me out of the echo chamber. :)

It isn't just about guiding passive users through content, though. My comment
was motivated by a little dilemma that I have been wrestling with:

I'm building a search engine and have written the first version as a React
app. I've been wondering if we shouldn't switch to a more traditional web page
structure.

Drew's post made me realize that I want to give my users - not passive - an
application experience so it's okay to stick with the current setup.

~~~
Karrot_Kream
> Drew's post made me realize that I want to give my users - not passive - an
> application experience so it's okay to stick with the current setup.

Yup, and I think that's fine! I love using the web applications that I do use.
I think we just need to take a hard look at what should be an application and
what shouldn't, especially given the target audience. Having SPAs with
infinite scroll to display a blog post really is just unnecessary.

------
mwcampbell
> The user is already comfortable with the way their browser works, and you
> will fail to capture the subtle nuances of their user agent with your pretty
> imitations.

Amen! One form of browser imitation that particularly annoys me is client-side
page loading. This is where JavaScript code intercepts activation of links,
loads the new page using XHR or the like, then updates the current DOM in-
place. Yes, this gives web developers the opportunity to prefetch pages or do
fancy animations. But the accessibility problem here is that there's no way
for an implementation of this technique to signal to a screen reader that a
page loaded just as if the browser itself had loaded the page. Yes, you can
use an ARIA live region to make a screen reader read your own message when
you've finished loading the page. But I want my screen reader to be in control
of what it does when a new page loads, e.g. automatically reading the contents
of the page, possibly in a user-configurable way. So I think it's better to
let the browser just load the page.

~~~
guntars
That sounds like a problem with the accessibility APIs then. I'd imagine that
the script that replaces the DOM in-place also uses History API to tell the
browser that this is a new page. At that point the browser should announce
that it's a new page and do whatever you've configured it to do, but I just
tried it in ChromeVox and it doesn't.

------
jakelazaroff
I think we all recognize that the web today has become overcomplicated. That
said, a lot of Drew's advice here is dogmatic.

 _> Leave the page at its default font size and avoid using custom fonts,
preferring to use vague selections like “sans-serif” and “monospace”._

Why? These are all easily customizable by the user.

 _> Try not to use a purely visual representation of information, such as an
icon: these should always be paired with text._

There are plenty of near–universally recognizable icons. Do your OS's windows
say "close" in the title bar, or do they simply have an X?

 _> Also avoid moving information around — animations and visually complex
state transitions._

Animations can be overused, but they can also serve an important purpose:
displaying the transition between states.

For example, when you scroll your mouse, does the window just snap to the next
page? Or does it go bit by bit so you can see where the new information comes
from, and where the old information goes? Which do you think is a better
experience?

~~~
phoe-krk
> _Try not to use a purely visual representation of information, such as an
> icon: these should always be paired with text._

Curious and purely technical question: are screen readers not using the alt
text of an <img ... /> tag? Does something like this not cause the "foo bar
baz" text to be read out twice in a row?

    
    
        <div><img src=... alt="Foo bar baz" />Foo bar baz</div>

~~~
extra88
Icons are often included using different methods that don't support the alt
attribute. Icon font systems like Font Awesome use CSS like this: .fa-
trash::before { content: "\f1f8"; }

Screen readers these days have good support of the ::before and ::after
pseudo-elements and most can the values of content properties but if the icon
font is using the Unicode private use area, a screen reader can't read it.
There's a new standard for content properties that allow for inclusion a text
alternative within the value but it's not broadly supported and in browsers
that don't support it, the visual content is not rendered.

Icons are also sometimes included using a background-image (maybe one that's
part of a sprite sheet) so a text alternative needs to be added somewhere.

aria-label and aria-labelledby attributes can provide text alternatives but
generally including the text in an adjacent element that's visually hidden is
more robust.

------
rdiddly
Of course. Analogous to how your closet is a lot easier to keep organized when
there's _less crap in it._

------
sansnomme
Drew, if you are reading this, please add Gogs/Gitea and OneDev to this list
of benchmarks on the performance page. Otherwise it is somewhat disingenuous
by comparing against Gitlab and GitHub since Rails and Ruby are hardly known
for their speed when it comes to web apps. Compare against Go and the JVM if
you want an honest comparison.

[https://forgeperf.org/](https://forgeperf.org/)

[https://gogs.io/](https://gogs.io/)

[https://gitea.io/en-us/](https://gitea.io/en-us/) (Gogs fork)

[https://onedev.io](https://onedev.io)

------
ChrisMarshallNY
Simplicity is difficult.

I use a comparison that I call "Nakamichi vs. Adcom."

Those of us...of a "certain age"...will remember these as top-shelf stereo
brands. They used to cost a bundle.

Nakamichi amps tended to be...engineer-friendly: [https://audio-
database.com/NAKAMICHI/amp/amplifier2.JPG](https://audio-
database.com/NAKAMICHI/amp/amplifier2.JPG)

Adcom amps tended to be a bit simpler:
[https://www.hifiengine.com/images/model/adcom_gfa-585_power_...](https://www.hifiengine.com/images/model/adcom_gfa-585_power_amplifier.jpg)

Both were pretty awesome, but they definitely "spoke to" different crowds.

I think that the debates over which is better would never be resolved.

I like to take the tack of "Make it simple, but no simpler than absolutely
necessary to get the principal task done."

This is really important in both usability and accessibility.

There's a famous quote from Josef Albers: _" In design, sometimes one plus one
equals three."_

Every element that we add to a design; whether functional or ornamental, can
have a combinatorial impact on complexity.

~~~
ratww
Off topic, but I noticed something funny: the simpler amp looks is closer to
what professional audio engineers use. We expect not having treble/bass
controls in our mixing monitors because we expect their response curve to be
as flat as possible.

(In practice some have controls to compensate for room issues, but we rarely
use, and just blame the room)

~~~
ChrisMarshallNY
I'm not surprised. The Adcom amp relies almost entirely on its preamp, which,
though simpler than the Nakamichi one, is a bit more complex.

On the other hand, this is the Nakamichi preamp:
[https://i.pinimg.com/originals/b9/7b/d6/b97bd60bcbedd59ddf4e...](https://i.pinimg.com/originals/b9/7b/d6/b97bd60bcbedd59ddf4ea972d17094c1.jpg)

------
gnicholas
> _Also avoid putting text over a variable background, such as a gradient or
> tiled background._

For sure. And especially don't have text over a background image that scrolls
beneath it. Since the image isn't likely uniform in color, you will end up
creating color/contrast problems.

------
chrismorgan
> _< meta charset="utf-8" />_

I’m curious: why do many people continue to use the trailing slash in many
places? As far as HTML parsers are concerned, it’s _completely_ useless. (On
HTML tags, that is. It’s still significant on MathML and SVG tags.) Doesn’t
seem to me that it will help authors to understand what’s going on, either—if
anything, it muddies the waters so that people will think that you can close
tags that way (you can’t).

------
brightball
Accessibility is one of those things that isn't taken seriously enough by many
people. It's good to see this on the front of HN.

~~~
ThibWeb
I share the same sentiment, but it would be even better if what’s shared was
more factual / less dogmatic – or in this case if sourcehut itself was a
better example. At a high level it’s somewhat correct that sticking to HTML-
only features is better, but otherwise there are a lot of issues with the
specific guidance in the post:

> Don’t use JavaScript to create custom input elements like text boxes

Sure. But some JavaScript would be valuable, for example to display validation
errors without a full page reload (try typing special characters in
[https://git.sr.ht/create](https://git.sr.ht/create)). This means screen
reader / keyboard users have to navigate back through the page, to the field,
and discover what the error is. A skip link would be nice too, that only takes
HTML.

> A good way of simulating the screen reader experience is to view your page
> with Lynx. Conveniently, Lynx does not support JavaScript.

Please don’t waste time in Lynx if you want to simulate the screen reader
experience – if you’re knowledgeable enough to have Lynx installed and use it,
you can learn to use a screen reader. There are good, free ones with every OS
these days. They are much more capable than Lynx, and support JavaScript just
fine.

> Avoid littering marketing garbage, superlatives, and ads for other parts of
> the site (or even ads outright) throughout your page, as skipping these is
> more difficult for a screen reader than for the typical visitor.

If your ad is wrapped in a `<section aria-label="My ad">` or aside, then it
should be very easy to skip.

The general guidance here is to focus on plain language. Sourcehunt should
avoid error messages like "Name must match [A-Za-z._-][A-Za-z0-9._-]*"

> In summary, if you want to get accessible quick, a good start for your new
> website might eschew npm install in favor of this:

Please update this template to have the `html` element with its `lang`
attribute defined. Not having "lang" defined means screen reader users have
the page read out in their browser’s default language, rather than the page’s
language, which can make the content unintelligible.

