22 ms·

Achieving Accessibility Through Simplicity

121 points by freddyym 6y ago

Nicksil 6y ago
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!"
- raspyberr 6y ago
  Something that I struggle with is finding how to do things properly. For example, search for "learn HTML" and you'll see all these online tutorials which I can already tell aren't gonna be what I'm actually looking for. How do you find out what to avoid and what standards to follow?
  - cxr 6y ago
    Sorry you didn't get an answer. Unfortunately, as with many things, the answer is, "be someone who already knows all the things that you're trying to learn", or, "be an old person who witnessed the progression in real time". You could try replicating the old person experience by starting with something like Dave Raggett's introduction to HTML or anything that focuses on HTML 4, and then look at why HTML5 added the things that it did. alistapart.com also hosts a lot of articles on this type of thing.
- Etheryte 6y ago
  I think a big part of the issue here, and one that's often overlooked, is that both browser vendors and the resulting spec are to blame for the emergence of many of these patterns. For example, making a button that visually looks like a link but keeps the correct semantics takes over 20 lines of non-trivial CSS, even today [1]. It is then no wonder that developers take the easier route of attaching event listeners to links instead. Realistically, if we want to have sites that are semantically sound, writing them the correct way should be so easy that you'd have to go out of your way to make them broken. Even with standards as new as HTML5 we have nonsense like the <article> and the <section> tag. Quoting MDN [2][3], "[the] <article> element represents a self-contained composition" and "[the] <section> element represents a standalone section". Even when I try my best to be semantically correct, I can't really tell when to use which. [1] https://stackoverflow.com/a/12642009/1470607 https://stackoverflow.com/a/12642009/1470607 [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/article https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ar... [3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section https://developer.mozilla.org/en-US/docs/Web/HTML/Element/se...
  - SilasX 6y ago
    >For example, making a button that visually looks like a link but keeps the correct semantics takes over 20 lines of non-trivial CSS, even today. Can you explain the use-case here? What about "being a button" do you need for the desired functionality? You just want it not to look like a button, while still acting like a button and looking like a link?
    - deleted 6y ago
      [deleted]
    - Deimorz 6y ago
      Over-simplifying, but in general a link should take you to a different url/destination. So if you want something that takes an action on the current page via JS but looks like a text link, it should be a <button> element styled as a link. Here's a good, extensive article on the differences and use-cases for links and buttons: https://css-tricks.com/a-complete-guide-to-links-and-buttons/ https://css-tricks.com/a-complete-guide-to-links-and-buttons...
- esperent 6y ago
  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.
  - ori_b 6y ago
    Yeah. With a lot of time and effort, you can get a result that's so good, it's indistinguishable from not doing anything special at all.
  - deleted 6y ago
    [deleted]
  - mwcampbell 6y ago
    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.
  - a1369209993 6y ago
    No, it's especially if you do it really well, because then it takes longer for people to realize it's broken.
  - chrismorgan 6y ago
    Trouble is that many of these things are impossible to do correctly. Taking some of the items in the list quoted: • Scrolljacking. The web doesn’t provide the APIs necessary to synthesise the effect of scrolling from mouse events. • Context menu behaviour: a tricky one, because there are some web apps where it seems reasonable and useful to provide your own context menu, but where it is conceivable that items in the native context menu may be desirable also. There’s no winning move here. There was a web API to handle this properly, where you could add items to the native context menu (<menu type=context>), but only Firefox has implemented it (and the writing is on the wall for it). I have no idea why the others have scuttled this seriously useful functionality. • Custom combo boxes: there’s a baseline of functionality (which most custom combo box widgets don’t cover properly anyway…), but beyond that each platform has its own subtleties that are not exposed in any way. If you truly want a custom combo box to feel native, you’ll need to sniff the platform and special-case. This leaves you open to getting things wrong in quite a few ways. • Custom scrollbars: all the relevant APIs are async and these days typically debounced a tad, so that it’s simply not possible to guarantee that your custom scrollbar will match the scroll container on every frame—and in almost all cases it will be delayed by at least one frame. (For the rest it is possible to do a flawless job. But it’s generally a much better idea to just not fiddle with things. I say this as someone who has made complex custom input controls and made sure they’re as close to perfect as is technically feasible without platform specialisation, but who definitely prefers to keep things simple. Oh, and I hate scrolljacking unconditionally.)
- hinkley 6y ago
  > Don’t use JavaScript to create custom input elements like text boxes, combo boxes, or scrollbars. You can style input elements heavily, and in some cases you can shadow them (associate a manufactured UI element with a real input element, and then conceal the real element). In fact for certain interactions you have to do this due to user agent hardening against CSRF attacks.
mwcampbell 6y ago
> 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 6y ago
  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.
  - deleted 6y ago
    [deleted]
- ratww 6y ago
  There are a few ways of making announcements in screen readers and handling SPA changes. I haven't tested them thoroughly, but had to implement a few aria alerts in a SPA. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alert_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
- marcusjt 6y ago
rdiddly 6y ago
Of course. Analogous to how your closet is a lot easier to keep organized when there's less crap in it.
gnicholas 6y ago
> 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.
jakelazaroff 6y ago
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?
- abjKT26nO8 6y ago
  >> 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. monospace and sans-serif are customizable. Helvetica isn't. Regarding font size, not that long ago there was a post here from someone who set "font-size: 1.4em" in their CSS, because they couldn't be bothered to set up HiDPI scaling on their system. Mind you this CSS rule doesn't set the font size to anything specific. It tells the browser "whatever size you wanted to use for this text, make it 1.4 times bigger". So if user set say 14px as their preferred font size, it would be 19.6 px instead. That's just asshole design.
  - jakelazaroff 6y ago
    > monospace and sans-serif are customizable. Helvetica isn't. Sure it is: https://support.mozilla.org/en-US/kb/change-fonts-and-colors-websites-use https://support.mozilla.org/en-US/kb/change-fonts-and-colors... > So if user set say 14px as their preferred font size, it would be 19.6 px instead. That's just asshole design. I don't see that as any different from saying "use 19.6px text unless the user specifically overrides it." Maybe the designer just likes big text! If a user doesn't, they can easily make it smaller.
Antecedent 6y ago
His website looks like crap and has no features. This is not a pragmatic approach if you are doing more than blogging.
- raspyberr 6y ago
  But what features would it need if it's just a blog post?
- keb_ 6y ago
  You're saying sourcehut has no feature? Nonsense, it has tons!
ChrisMarshallNY 6y ago
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_amplifier.jpg https://www.hifiengine.com/images/model/adcom_gfa-585_power_... 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 6y ago
  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 6y ago
    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/b97bd60bcbedd59ddf4ea972d17094c1.jpg https://i.pinimg.com/originals/b9/7b/d6/b97bd60bcbedd59ddf4e...
Antecedent 6y ago
Why don’t we just make websites for the deaf blind and retarded and leave the web alone?
- mwcampbell 6y ago
  We want and need to use the websites and applications that our peers are using.
  - ratww 6y ago
    Piggy-backing on your answer, which I also agree with (sorry, parent was flagged): Proper accessibility normally makes websites better for people who don't need accessibility features. At worst it doesn't make a difference. Lack of accessibility normally makes websites worse for everyone.
  - SilasX 6y ago
    I can't seemed to reply to the flagged/dead parent, but -- despite the harsh language -- it's actually an insightful question with a good answer, one which (IMHO) I gave before [1]. Basically, regular HTML was the language for the blind! It has everything, by design, that the blind should need to access all their content with a screen reader. Then, they bolted on stuff that broke that use case. So, even if we did come up with a separate language, we would need to prevent it from having the same things happen to it. [1] https://news.ycombinator.com/item?id=20225291 https://news.ycombinator.com/item?id=20225291
    - mwcampbell 6y ago
      > it's actually an insightful question How so? I replied because I didn't want to pass on an opportunity to advocate for equal access, and I thought the person asking that question might be genuinely ignorant, e.g. growing up in a culture where it goes without saying that people with disabilities are outcasts. In other words, I wanted to be charitable and not write them off as a troll. But I don't see how it's an insightful question.
zomglings 6y ago
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 6y ago
  > 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.
sansnomme 6y ago
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
brightball 6y ago
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 6y ago
  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.
chrismorgan 6y ago
> <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).

121 points by freddyym 6y ago

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!"

raspyberr 6y ago
Something that I struggle with is finding how to do things properly. For example, search for "learn HTML" and you'll see all these online tutorials which I can already tell aren't gonna be what I'm actually looking for. How do you find out what to avoid and what standards to follow?
- cxr 6y ago
  Sorry you didn't get an answer. Unfortunately, as with many things, the answer is, "be someone who already knows all the things that you're trying to learn", or, "be an old person who witnessed the progression in real time". You could try replicating the old person experience by starting with something like Dave Raggett's introduction to HTML or anything that focuses on HTML 4, and then look at why HTML5 added the things that it did. alistapart.com also hosts a lot of articles on this type of thing.
Etheryte 6y ago
I think a big part of the issue here, and one that's often overlooked, is that both browser vendors and the resulting spec are to blame for the emergence of many of these patterns. For example, making a button that visually looks like a link but keeps the correct semantics takes over 20 lines of non-trivial CSS, even today [1]. It is then no wonder that developers take the easier route of attaching event listeners to links instead. Realistically, if we want to have sites that are semantically sound, writing them the correct way should be so easy that you'd have to go out of your way to make them broken. Even with standards as new as HTML5 we have nonsense like the <article> and the <section> tag. Quoting MDN [2][3], "[the] <article> element represents a self-contained composition" and "[the] <section> element represents a standalone section". Even when I try my best to be semantically correct, I can't really tell when to use which. [1] https://stackoverflow.com/a/12642009/1470607 https://stackoverflow.com/a/12642009/1470607 [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/article https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ar... [3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section https://developer.mozilla.org/en-US/docs/Web/HTML/Element/se...
- SilasX 6y ago
  >For example, making a button that visually looks like a link but keeps the correct semantics takes over 20 lines of non-trivial CSS, even today. Can you explain the use-case here? What about "being a button" do you need for the desired functionality? You just want it not to look like a button, while still acting like a button and looking like a link?
  - deleted 6y ago
    [deleted]
  - Deimorz 6y ago
    Over-simplifying, but in general a link should take you to a different url/destination. So if you want something that takes an action on the current page via JS but looks like a text link, it should be a <button> element styled as a link. Here's a good, extensive article on the differences and use-cases for links and buttons: https://css-tricks.com/a-complete-guide-to-links-and-buttons/ https://css-tricks.com/a-complete-guide-to-links-and-buttons...
esperent 6y ago
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.
- ori_b 6y ago
  Yeah. With a lot of time and effort, you can get a result that's so good, it's indistinguishable from not doing anything special at all.
- deleted 6y ago
  [deleted]
- mwcampbell 6y ago
  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.
- a1369209993 6y ago
  No, it's especially if you do it really well, because then it takes longer for people to realize it's broken.
- chrismorgan 6y ago
  Trouble is that many of these things are impossible to do correctly. Taking some of the items in the list quoted: • Scrolljacking. The web doesn’t provide the APIs necessary to synthesise the effect of scrolling from mouse events. • Context menu behaviour: a tricky one, because there are some web apps where it seems reasonable and useful to provide your own context menu, but where it is conceivable that items in the native context menu may be desirable also. There’s no winning move here. There was a web API to handle this properly, where you could add items to the native context menu (<menu type=context>), but only Firefox has implemented it (and the writing is on the wall for it). I have no idea why the others have scuttled this seriously useful functionality. • Custom combo boxes: there’s a baseline of functionality (which most custom combo box widgets don’t cover properly anyway…), but beyond that each platform has its own subtleties that are not exposed in any way. If you truly want a custom combo box to feel native, you’ll need to sniff the platform and special-case. This leaves you open to getting things wrong in quite a few ways. • Custom scrollbars: all the relevant APIs are async and these days typically debounced a tad, so that it’s simply not possible to guarantee that your custom scrollbar will match the scroll container on every frame—and in almost all cases it will be delayed by at least one frame. (For the rest it is possible to do a flawless job. But it’s generally a much better idea to just not fiddle with things. I say this as someone who has made complex custom input controls and made sure they’re as close to perfect as is technically feasible without platform specialisation, but who definitely prefers to keep things simple. Oh, and I hate scrolljacking unconditionally.)
hinkley 6y ago
> Don’t use JavaScript to create custom input elements like text boxes, combo boxes, or scrollbars. You can style input elements heavily, and in some cases you can shadow them (associate a manufactured UI element with a real input element, and then conceal the real element). In fact for certain interactions you have to do this due to user agent hardening against CSRF attacks.

mwcampbell 6y ago

> 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 6y ago
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.
- deleted 6y ago
  [deleted]
ratww 6y ago
There are a few ways of making announcements in screen readers and handling SPA changes. I haven't tested them thoroughly, but had to implement a few aria alerts in a SPA. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alert_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
marcusjt 6y ago

rdiddly 6y ago

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

gnicholas 6y ago

> 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.

jakelazaroff 6y ago

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?

abjKT26nO8 6y ago
>> 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. monospace and sans-serif are customizable. Helvetica isn't. Regarding font size, not that long ago there was a post here from someone who set "font-size: 1.4em" in their CSS, because they couldn't be bothered to set up HiDPI scaling on their system. Mind you this CSS rule doesn't set the font size to anything specific. It tells the browser "whatever size you wanted to use for this text, make it 1.4 times bigger". So if user set say 14px as their preferred font size, it would be 19.6 px instead. That's just asshole design.
- jakelazaroff 6y ago
  > monospace and sans-serif are customizable. Helvetica isn't. Sure it is: https://support.mozilla.org/en-US/kb/change-fonts-and-colors-websites-use https://support.mozilla.org/en-US/kb/change-fonts-and-colors... > So if user set say 14px as their preferred font size, it would be 19.6 px instead. That's just asshole design. I don't see that as any different from saying "use 19.6px text unless the user specifically overrides it." Maybe the designer just likes big text! If a user doesn't, they can easily make it smaller.

Antecedent 6y ago

His website looks like crap and has no features. This is not a pragmatic approach if you are doing more than blogging.

raspyberr 6y ago
But what features would it need if it's just a blog post?
keb_ 6y ago
You're saying sourcehut has no feature? Nonsense, it has tons!

ChrisMarshallNY 6y ago

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_amplifier.jpg https://www.hifiengine.com/images/model/adcom_gfa-585_power_... 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 6y ago
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 6y ago
  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/b97bd60bcbedd59ddf4ea972d17094c1.jpg https://i.pinimg.com/originals/b9/7b/d6/b97bd60bcbedd59ddf4e...

Antecedent 6y ago

Why don’t we just make websites for the deaf blind and retarded and leave the web alone?

mwcampbell 6y ago
We want and need to use the websites and applications that our peers are using.
- ratww 6y ago
  Piggy-backing on your answer, which I also agree with (sorry, parent was flagged): Proper accessibility normally makes websites better for people who don't need accessibility features. At worst it doesn't make a difference. Lack of accessibility normally makes websites worse for everyone.
- SilasX 6y ago
  I can't seemed to reply to the flagged/dead parent, but -- despite the harsh language -- it's actually an insightful question with a good answer, one which (IMHO) I gave before [1]. Basically, regular HTML was the language for the blind! It has everything, by design, that the blind should need to access all their content with a screen reader. Then, they bolted on stuff that broke that use case. So, even if we did come up with a separate language, we would need to prevent it from having the same things happen to it. [1] https://news.ycombinator.com/item?id=20225291 https://news.ycombinator.com/item?id=20225291
  - mwcampbell 6y ago
    > it's actually an insightful question How so? I replied because I didn't want to pass on an opportunity to advocate for equal access, and I thought the person asking that question might be genuinely ignorant, e.g. growing up in a culture where it goes without saying that people with disabilities are outcasts. In other words, I wanted to be charitable and not write them off as a troll. But I don't see how it's an insightful question.

zomglings 6y ago

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 6y ago
> 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.

sansnomme 6y ago

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

brightball 6y ago

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 6y ago
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.

chrismorgan 6y ago

> <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).