Hacker News Reader

Comment by CJefferson | Hacker News Reader

This does look really nice, and the author should be proud, however I wanted to make a general comment (which isn't a critism of this website).

If you aim is to help people who want pure text-based interfaces (the blind in particular), this is much worse than a proper HTML page, which they can easily explore by headers. Well-formed HTML is actually one of the most accessible formats, and drawing boxes with CSS (rather than ASCII art) is also much better, as a screen reader would try to read the art, and get confused by boxes next to each other.

View on HN

To add – the two aren't mutually exclusive. You can have page layouts with divs and correct tags that screen readers can understand AND draw ascii borders around it.

Yep exactly, heck you could just link in tui.css and go wild making something that looks like text but is 100% accessible with ARIA labels and semantic markup: https://github.com/vinibiavatti1/TuiCss

Couldn't he just want... a plain-text interface?

Why are we assigning motives to creations where none is stated? ASCII art loads fast and the miniscule stylesheet and script barely slows anything down.

Plenty of people who aren't disabled like minimalist interfaces, because minimalist interfaces tend to stay relatively static.

Plus, in this case, the main utility seems to be that there's a single place you can check the results of any mainstream sports event, rather than going through the million hoops to get search engines to give you a page where you can find results.

This site is HTML, replacing <div> with <table> wouldn't change that. Tabular data can still be plain text. It's just rendered in tables instead of divs and spans.

Plain text is good because it

1. Loads fast 2. Can be parsed easily

<table>s load just as fast, and can be parsed much faster by humans and computers alike.

Either don't use HTML and use plain text instead, or use it correctly. This is all costs of markup without any benefit. Bring accessibility in the mix (which we should always do) and it's a non-starter.

> Either don't use HTML and use plain text instead, or use it correctly.

Says who? The owner of the website here owes us nothing.

I mean it as a constructive criticism, not a pull request. It's a cool project (enough that I wanted to see how it's built).

Personally, I love the site, and I'm glad it is the way it is: It looks and feels better than any plausible alternative. It sure seems like it has all of the benefits and only one of the drawbacks (vaguely inaccessible).

A person can just make something for their own enjoyment. It's not the end of the world.

The primary drawback is that it's not plain text, so it doesn't have the benefit that a plain text format would.

This isn't "plain text." It's still laid out via HTML (and CSS). HTML tables somehow get a bad rap, but they are perfect for tabular data, which most of this data displayed on this particular site is. A proper "plain text" interface in HTML would be the data wrapped in a PRE tag, right?

To be clear, regardless of the HTML layout, I do like this site, because I can quickly and easily check NHL scores and standings without the cruft that comes from most sporting websites.

> HTML tables somehow get a bad rap, but they are perfect for tabular data, which most of this data displayed on this particular site is.

For me, not supporting some kind of sorting natively makes them not perfect. It's really important for me when reading tabular data to have that option.

To clarify: Are you indicating that, as a user dependent on screen readers, that this site is difficult to use for you?

Do other users who depend on screen readers have an experience they’re willing to share about visiting this site?

As someone with friends who use screen readers, I notice when sites are close, but not quite there. Many websites are just a lost cause, but this is very close to very accessible :)

The main limitation is it would be nice if the sections were labelled, either with a <hx>, or <section>, to make it easier to jump around the page.

The ascii art gets read, which is a bit annoying, aria-hidden="true" will make the ascii art not get read out as text.

The best option is to try out with a screen reader -- on both windows + mac a decent screen reader is built in (it's worth best with the default browser, safari on mac, edge on windows). I'm not expert on screen reading on Linux.

This is something that frustrates me: it's actually really hard to design for screenreaders because it's hard to actually check the results in a free/volunteer context. So you often just have to just hope you're being "semantic" enough.

And I did try to use Orca but I just could not get it to work, the TTS service was sulkily disinclined to accept any requests.

Nowadays it's really easy to check on mac + windows, as the built in stuff is "good enough", particularly if you use the OSes default browser (Safari and edge respectively).

I realise that doesn't help Linux/BSD users.

Firefox's Accessibility tree inspector is nice.

Link for the curious: https://developer.mozilla.org/en-US/docs/Tools/Accessibility...

Try IBM's Equal Access Checker browser extension

https://github.com/IBMa/equal-access

Why not also include an audio file generated from the text of the page with TTS.

I believe vision-impaired users would greatly prefer their own TTS, in part because many can listen at 5-10x speed since they're so used to hearing that particular voice.

"... would..."

It sounds as though the author has not actually asked vision-impaired users.

And of course audio is not only for vision-impaired users.

I can play audio directly from a webpage at 5-10x speed easily, but I use the command line programs like ffmpeg/mplayer/mpv/vlc, not a browser like Chrome.

Assuming a Google employee's belief reflects what all web users actually prefer (doubtful!), websites could offer a variety of audio with the same TTS voices that screen readers use.

There is no need to include it, since that's the point of screen readers and all other client-side assistive software.

The problem is that in this page's case all of the decorative text like borders will be "read out" as well.

By including the audio file, which only includes the readable text, one can avoid the problem of screen readers trying to read ASCII art, decorative elements, etc.

Some news websites, for example Bloomberg, have been including audio files for years. Wikipedia also offers audio files created with TTS.

Reply on news.ycombinator.com