There's nothing like working on screen reader compatibility to build a bit of empathy.

At my job we worked with an accessibility agency to train our devs and designers on web accessibility. It's really enlightening to see someone navigating smoothly with just sound or with 800% zoom. And very embarrassing when your menus just repeat the same "list item" label 5 times because of poor use of semantic HTML.

That makes me think, how does one learn to use a screen reader? (Or alternatives for other handicaps)

It seems fairly technical and challenging to learn, but I feel it would make sense for abled engineers to practice using those.

I personally wouldn’t even know where to start, I only enabled the screen reader a few times by mistakes and have no idea how I could learn to be effective with it if I need to at some point in my life.

Just turn off your monitor.

You can also learn Linux by just uninstalling Windows. 15 minutes of good starting material will save you untold amounts of unnecessary headache though.

If you enable VoiceOver on iOS, you can perform a gesture to enable “screen curtain” which turns off display rendering: a triple-finger triple tap.

Great way to test your app for accessibility.

> That makes me think, how does one learn to use a screen reader? (Or alternatives for other handicaps)

VoiceOver on Mac or NVDA on Windows are good, free options.

There's an accessibility playlist on Youtube that provides an introduction to both:

https://www.youtube.com/watch?v=5R-6WvAihms&list=PLNYkxOF6rc...

A more in-depth demo:

https://www.youtube.com/watch?v=y0m7VEHoXMI

I've been learning screen readers in my spare time because it seems like a nice screen off way to browse content in bed. It's servicable and maybe even viable way to work if more of the web was tailored for it.

Surprised it isn’t more common, I would expect nerdy abled people to show off to their friends their cool screen reading skills, just because it’s such a niche, technical, and weird thing to do.

I may try out during the weekend.

It's been a while, but I'm not convinced there is a truly accessible date picker out there. Allowing manual typing of the date seems like the best and only viable option.

Also just typing the date manually is almost always faster than using a date picker. Or at least that's how I perceive it, which is all that matters. I hate apps that force me to take my hands off the keyboard and use the mouse.

Yep. They increasingly break addons that (try to) enable me to do everything from the keyboard.

For motel stays, it's nice/reassuring to see/select by day-of-the-week.

Also every year I get a little more resentful of spinner wheels for year of birth that start at the current year.

As soon as we solve the whole US-using-a-different-date-format-to-the-rest-of-the-world problem, absolutely. Having it automatically display the day of the week as you type the date would be a big help though.

The problem is that "just typing the date manually" actually has quite complex i18n issues. It can be done well, but that generally means you make the user explicitly confirm the date they just typed.

<input type="date"> is a pretty good option, and it lets you type in the date manually if you'd like.

Somewhat agree, but when you say typing the date you mean ISO 8601, right?

That is the only sensible format for dates, and while all developers probably agree on that it isn't a given that all your users will.

As input, any permutation of full year, full month name, and day of the month is unambiguous wrt any date on or after January 1, 100 CE* and therefore sensible, no matter how unusual/obscure. (The issue of handling multiple languages isn't a rejoinder to this, because that's just localization, which is an umbrella that should already exist so treating it like a new requirement would just be double counting.) This is how every browser-native datepicker should already work, although regretfully they do not.

* 32 CE, if you want to really get down to it

Noone would expect that so you'd need to explain it and get people to spell correctly. Not convinced it is a good UX.

"Just localization" isn't "just". Many people have the wrong localization on their computers. Partly because they don't always communicate in their native language. But also because google et. al. are doing such a piss poor job of it.

It is also always weird if your are on an international site. Enter everything in English and then suddenly is expected to enter some fields in your native language.

> Noone would expect that

You are moving the goalposts.

> "Just localization" isn't "just". Many people have the wrong localization on their computers.

Think about this for a minute longer. Do you have an example or scenario for the use of a Web site where the author can fall into a pit of success (despite having the user's wrong localization) on all things except for dates and that would be broken by allowing* this date input method?

Even ignoring that:

What I said was that "any permutation of full year, full month name, and day of the month is unambiguous". There are a finite number of months and a finite number of localized tokens for representing those months. Do you have an example of two different locales that use the same token (or token sequence) to denote different months on the calendar?

* the word "allowing" playing a crucial role here

Only if you use a proleptic calendar. If you are entering dates from historic documents, you need to know which calendar the author of the document was using

Did you read my comment in the parenthetical?

Did you ever try `cal 9 1752`

What about it?

> As input, any permutation of full year, full month name, and day of the month is unambiguous wrt any date on or after January 1, 100 CE* and therefore sensible, no matter how unusual/obscure

If you are using a proleptic Gregorian (or Julian, but why on earth would you do that) calendar, sure.

If its not one of those (but its still the Roman-derived Christian calendar in some form), there are ambiguities, and if its any other calendar, it may have ambiguities and/or the elements needed to specify a date may be different, and the CE/AD year is likely not an element and not relevant to whethe or not their are ambiguities.

The comment I replied to specified ISO 8601. The Gregorian constraint is a given.

I put in a whole clause in my original comment to preempt this flavor of pedantic sniping that involves applying double standards. And yet here we are.

Here is an idea:

The devs of a site (or an application) are in a video call, with screen sharing or whatever is useful, with a user who has accessibility needs and is using their site/program. A bunch of other devs sit in on it, muted, just learning. Then the devs throw some money in the pot and the user who did the testing gets paid for their time. Everybody wins.

Oh, and if all participants agree, the stream is made available for subscribers, and then the user gets royalties off that, too.

Does this exist? Can someone make it?

Not a video call but a recording made by the user, and not specifically for accessibility testing, but UserTesting is something similar like that.

You just described what is known as "user testing". They can happen in person, like a focus group, or remotely. Companies reach out to the public for "random" users that fit the given criteria and are paid for their time. You can also use a 3rd party service who will pair you with random testers, for example https://www.usertesting.com/

> It was fancy alright

I don't want to overdo it with high-falutin' theorizing, but I think your firm's definition of "fancy" might be missing some crucial aspects, or maybe "fancy" isn't the right term. Maybe it was "flashy," or "gaudy," or "decorative"? Maybe it was "branded"? Or did it actually offer sighted users a more effective UX?