Live data from Hacker News

The unreasonable effectiveness of simple HTML

shkspr.mobi

351–360 of 387 posts

Re: The unreasonable effectiveness of simple HTML

#351
post #305

Earlier quoted context omitted.

PDFs can be accessible, and many of them are! Everyone who works with PDF needs to know about PDF/A: https://en.wikipedia.org/wiki/PDF/A PDF/A is a small family of sub-formats to PDFs which amount to the accessible subset of PDF + some requirements. PDF/A and PDF/UA are mandated by a variety of governments for PDF distribution. They're very suitable to archival and are accessible (screenreaders can work with them, th…

PDF/A isn't necessarily accessible. First, PDF is very hard to impossible to scale for people who need big writing, due to reflowing being unavailable or not working properly. Text in PDF/A can still be a big image, e.g. in a scan for archival purposes, if you are "lucky" there is an OCR overlay, but then your screenreader reads OCR'd text which is hit-or-miss. And text ordering is supposed to be "reading order" in P…

There is no OCR overlay in /A, what are you talking about? It should be the original text.

If it's scanned copies then all it is is a bunch of images, not A compliant.

Re: The unreasonable effectiveness of simple HTML

#352

This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though. The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can function properly. People who choose to eschew these standard components very frequently end up with a site which is unu…

One of the great things about accessibility is that it often doesn't just benefit people with disabilities. My wife and I have watched a lot of TV in the past year with the volume down and captioning on, while we enjoy some down time while our baby is sleeping. A ramped entrance to a building allows wheelchair-bound folks access, but it also helps able-bodied people using delivery dollies. Making simple, lightweight…

The troublesome grey area is the part where people do it for control.

There is also sort of "exclusive design" that is practiced. You know - where you can't get comfortable on a park bench because you might sleep on it, or a ramp or stairs are built to exclude skateboards.

Same thing happens with websites, to "control" adblockers or "reader mode" and other nonsense.

Re: The unreasonable effectiveness of simple HTML

#353

Earlier quoted context omitted.

One of the great things about accessibility is that it often doesn't just benefit people with disabilities. My wife and I have watched a lot of TV in the past year with the volume down and captioning on, while we enjoy some down time while our baby is sleeping. A ramped entrance to a building allows wheelchair-bound folks access, but it also helps able-bodied people using delivery dollies. Making simple, lightweight…

Another great example of this is effective keyboard navigation is both an accessibility feature and something you can sell as a feature for power users who like to get things done as quickly and effortlessly as possible.

Like the apple face tracking mouse pointer, where you raise your eyebrows to click.

https://youtu.be/wAVij3tTAxE

Re: The unreasonable effectiveness of simple HTML

#354
post #305

Earlier quoted context omitted.

PDF/A isn't necessarily accessible. First, PDF is very hard to impossible to scale for people who need big writing, due to reflowing being unavailable or not working properly. Text in PDF/A can still be a big image, e.g. in a scan for archival purposes, if you are "lucky" there is an OCR overlay, but then your screenreader reads OCR'd text which is hit-or-miss. And text ordering is supposed to be "reading order" in P…

There is no OCR overlay in /A, what are you talking about? It should be the original text. If it's scanned copies then all it is is a bunch of images, not A compliant.

Scanned images are totally PDF/A-compliant. The standard is just about reproducible archiving, nothing else. Bitmaps are perfectly reproducible and pass every compliance check. That PDF/A is more accessible than any old PDF is just a side-effect.

Re: The unreasonable effectiveness of simple HTML

#355
post #141

Earlier quoted context omitted.

One of the great things about accessibility is that it often doesn't just benefit people with disabilities. My wife and I have watched a lot of TV in the past year with the volume down and captioning on, while we enjoy some down time while our baby is sleeping. A ramped entrance to a building allows wheelchair-bound folks access, but it also helps able-bodied people using delivery dollies. Making simple, lightweight…

> One of the great things about accessibility is that it often doesn't just benefit people with disabilities. I really love how Microsoft's design team has pushed this with their “Inclusive Design” concept[1] and highlighting how any sort of disability can be situational (holding a baby), temporary (broken arm), or permanent (missing arm) but we often only think of those in the last context despite there being orders…

1. With due respect to various useful elements of design in Microsoft's work - this booklet reads like "We design for black people! We design for LGBT people! We design for disabled people! Look at us, we're so morally and politically superior!"

2. Microsoft makes software which costs a lot of money (for most people in the world); often a lot of money. One of the main problems people with disabilities have is low income and lots of expenses.

3. Microsoft makes software which hogs resources and thus runs poorly, or not at all, on older or simpler, low-power devices. This also not very accessible. So it might have a perfect UI experience - on the computer people don't have. Admittedly, though, this is not as bad of a problem in the past few years.

4. I wonder how actually accessible MS apps and Windows actually are. Considering how they've botched a lot of their designs in recent years even for normies (Metro; Ribbons).

Re: The unreasonable effectiveness of simple HTML

#356

Earlier quoted context omitted.

Eh, 98.24% of all users worldwide can use TLS 1.2: https://caniuse.com/?search=tls%201.2 I'm not willing to make security exceptions to support devices from 2011. "HTTPS by default" lifts all boats: people who would MITM your users can't tell if they're reading your nice blog or a critique of their local government, and that's a good thing.

> Eh, 98.24% of all users worldwide can use TLS 1.2: https://caniuse.com/?search=tls%201.2 That's 98.24% of users captured by CanIUse's sources (which seems to be StatCounter). Like most things on the Internet, that's a bubble - the bubble of users who visit statcounter-infested websites, and are able to run their scripts. And the point of the original post is to think outside the bubble. Not in all cases - if you're…

That's a tough one, because the examples you gave are exactly the ones that I don't want a shady ISP or other interested party to my snooping. I'm not unsympathetic, and genuinely feel bad for the people stuck with truly ancient systems. But at some point, you have to do the analysis of whether it's better to 1) give secure communication to everyone who can have it, or 2) retain insecure communications to support an ever-shrinking pool of people who can't/won't upgrade. I think we're at the point where #1 is more important.

And honestly, I think a lot of people in the second group are there because they bought smartphone in 2007 and won't upgrade because "if it ain't broke, don't fix it". Well, now it's broken. Fix it.

Re: The unreasonable effectiveness of simple HTML

#357

Earlier quoted context omitted.

> and if you're doing crud stuff, most of the work is frankly done for you. React sucks for large complex forms unless you pair it with another technology or two. Want to write a crud app fast? C# and Winforms. Couple years back, I once did a prototype of a web app in C# and Winforms connected to Firebase. Less than a day, done. Month later, had it working in React. Granted the React website looked nice, but the diff…

That's really interesting, I should look into that pattern, maybe it can be applied elsewhere (I have to maintain a vb6 application at work, and I'm not terribly interested in doing that anymore). Yeah working with redux sucks in general imo, I try to avoid it when I can. If I can get away with it, I try to avoid the problem entirely by using hasura as a backend. But sometimes that's not viable.

> That's really interesting, I should look into that pattern, maybe it can be applied elsewhere (I have to maintain a vb6 application at work, and I'm not terribly interested in doing that anymore).

I hadn't used C# for years, I was shocked that the winforms designer duct taped to a community contributed Firebase library, was able to get a prototype out in hours.

I had been using JS for 2 years at that point. I estimate at 10x-15x productivity boost in C# over JS.

The C# tooling is just that good.

Now if I'd been trying to learn XAML or something at the same time, eh, probably wouldn't have gone as well.

Of course the downside here is that a Winforms app is hard to distribute, and usable only on Windows desktops.

The react web app was, well, beautiful, and usable everywhere.

But I could have written the C# app once for every platform I care about and still been better off.

Ugh, I am sad that Winforms is only ever going to be Win32 based.

Re: The unreasonable effectiveness of simple HTML

#358
post #141

Earlier quoted context omitted.

> One of the great things about accessibility is that it often doesn't just benefit people with disabilities. I really love how Microsoft's design team has pushed this with their “Inclusive Design” concept[1] and highlighting how any sort of disability can be situational (holding a baby), temporary (broken arm), or permanent (missing arm) but we often only think of those in the last context despite there being orders…

1. With due respect to various useful elements of design in Microsoft's work - this booklet reads like "We design for black people! We design for LGBT people! We design for disabled people! Look at us, we're so morally and politically superior!" 2. Microsoft makes software which costs a lot of money (for most people in the world); often a lot of money. One of the main problems people with disabilities have is low inc…

It's disturbing that you find trying to be inclusive offensive because you perceive them as political opponents. I mean, who cares what people's political leanings are if they are making things better for people who haven't been well-served historically?

Similarly, while Microsoft software isn't free nothing in computing is and it seems like an odd angle to criticize an effort to help make their products better based on decisions made by other people in different parts of a huge company, or to criticize them for things in the past which they've since corrected.

Re: The unreasonable effectiveness of simple HTML

#359

Earlier quoted context omitted.

Almost every JS app I have seen uses a tags though. Even if they are just links to # pages. With most router libraries you can even use real paths and it works all on the front end. Sounds like you found one anecdotal case that didn't know this.

Maybe I wasn't clear -- What I meant to say is that the curriculum barely covered tags, but instead started just with JS DOM manipulation, which meant students were using document.location on click events since they weren't taught anything else. This isn't a criticism of JS best practices, instead it's a criticism of how it's taught, specifically in this curriculum that's sold as a white-label curriculum and used by…

Exactly. And sometimes they're not even taught it! But since they also weren't taught the foundations, they also won't know how to "ask" questions. So they end up searching for "how do go to another page using Javascript", which will obviously yield results with window.location.

Re: The unreasonable effectiveness of simple HTML

#360

Earlier quoted context omitted.

You have a great point. Browser UI elements are stuck in time and all the attention now is directed to things that Google can make money from (e.g. DRM, sandbox for rich apps/extensions, webrtc for their video call products, etc) but your cited site is not a good advocacy of that. Not even the most exalted UI framework fix the most obvious problems with those either. e.g. tables still won't hold the header and first…

> e.g. tables still won't hold the header and first column(s) while scrolling. https://caniuse.com/css-sticky position:sticky works on tables.

It's all red :( No support anywhere but Firefox. In fact, I will now use this URL as my main argument in support of firefox!

even the grand-parent, javascript infused solutions, only two out of 20 support this extremely basic and obvious use case.

Web UI standards are a joke. Everyone involved only cares about rich ads and accordions/carrousels which are lame ways to shove lots of content in a badly designed space.

Post reply on HN