Accessibility at Trivago | Hacker News Reader

Accessibility at Trivago

tech.trivago.com

56 pointsrobin_reala10 comments

                Please upgrade your browser

We're sorry, but we no longer support this version of your web browser. Please upgrade to a new version to be able to access our site.

Download browsers here [http://outdatedbrowser.com]

   trivago Copyright 2017 trivago | All rights reserved.

Nice.

Possibly someone is trying to make guesses based on User-Agent header? Then coercing user to install certain third party software?

In any event, the result is: if "wrong" User-Agent header, then no access.

Moreover, robots.txt does not list the UA header I used to test accessibility.

Idea: If website authors prefer certain browsers to be used, then provide machine-readable list of acceptable browsers. Better yet, provide list of acceptable User-Agent headers.

(Is this list provided by outdatedbrowsers.com? Not quite. For example, curl works fine and it is not listed.)

IMHO: User-agent header is a header not a browser. As in the old adage that "an IP address is an IP address assigned to an interface, not a computer."

The fact is, in some cases, the user is the only one who really knows what "browser" she is using.

I think the move towards accessibility is great. I didn't know about pa11y so will probably bring it (or something similar) into our own build cycle to help keep track of WCAG issues.

We also find it's useful to test out the core functionality using the keyboard, but extend that to using a text only browser and Chromevox so we can get a feel for what user stories would get broken if JS breaks, the user is trying to use the tools in older/incompatible browsers or the user has visual impairment. So far, it's been quite enlightening and we've not run into anything within the core functionality that couldn't be fixed with better UX and competently written HTML.

For what it’s worth, ChromeVox doesn’t see much use from users of assistive tech. If you don’t want to pay for JAWS you’re better off testing with NVDA on Windows or VoiceOver on Mac / iOS.

Thanks for the info! We may well switch over if that's what users are more likely to be using.

It’s very difficult to tell what people are actually using as assistive tech interfaces with browsers rather than connecting to the site directly, but you can run surveys. We did one last year on GOV.UK and found JAWS at 38.5%, ChromeVox at 1%: https://accessibility.blog.gov.uk/2016/11/01/results-of-the-...

Again, thanks for the information. I'll definitely take that back to my team and see what we can improve on!

To provide some practical reasoning behind this: ChromeVox and software like it, naturally, runs in the browser. A blind person is unlikely to have a visual impairment which means they can't use a browser but can use every other part of the system without speech feedback. Therefore, system-wide screen readers see much higher use - who wants to keep switching between screen readers all the time?

On the plus side, though, keyboard predictability breeds accessibility, so any testing in this area is often better than none.

I am a little sceptical of using A/B tests on accessibility features. What, precisely, is being measured here?

The acceptance criteria for accessibility features are narrow to a specific group of users (actually, the users fall on a continuous spectrum). Furthermore, there are legal, ethical and moral obligations. Would those be thrown out if the A/B test was a fail?

> Would those be thrown out if the A/B test was a fail?

It sounds like it, yes.

> there are legal, ethical and moral obligations.

From the evidence in this article, Trivago don't give a shit (or didn't)

In these cases, no, they wouldn't be thrown out. The aim is always to accept accessibility changes but they still need to be tested first, just in case they have negative affects which would need further investigation to be fixed.

Reply on news.ycombinator.com