
Accessibility at Trivago - robin_reala
http://tech.trivago.com/2017/09/26/accessibility-at-trivago/
======
feelin_googley

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

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

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

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

~~~
robin_reala
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-...](https://accessibility.blog.gov.uk/2016/11/01/results-of-the-2016-gov-
uk-assistive-technology-survey/)

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

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

------
beejiu
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?

~~~
rtb
> 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)

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

