It happens more often then you might imagine for a number of reasons:
Disabled people, for whom static rendering and full-page reloads are typically still more (not exclusively, but more, and more easily) accessible.
Clients who aren’t people at all - search engine spiders (not just Google, but internal search engines), automatic translation services, semantic query agents - you name it.
Lightweight devices that may have constrained battery power, memory or CPU speed, and hence which can’t afford expensive client-side processing - anything from low-end smartphones to smartwatches to devices like live tattoos or contact lenses or flexible e-ink devices that haven’t even been invented yet but could become huge in the next 5-10 years (exactly like smartphones did between 2007 and 2017).
Devices without a graphical interface - again, non-human scripts, braille “displays”, semantic aggregators, etc.
Devices without and mice or touchscreens - keyboard-only users, kiosk systems, voice control, users using non-traditional input devices, etc. Any device that doesn’t correctly download your code - like mobile devices on a dodgy connection that craps out halfway through, or adblockers that block random JS scripts because it has the string “ad” in the name, or corporate networks with over-eager network filtering policies, or because your static-asset server or CDN goes down.
Troops that are deployed overseas that have JS blocked in their browsers.
There are plenty of armed servicemen/women who have access to computers and yes JS might be disabled for a reason, but thats the rub, how does your application work in that circumstance. Having a f-em attitude speaks volumes.
It doesn’t handle ALL websites correctly, it’s not possible. When the content isn’t in the DOM to be traversed it can’t be read back, that’s the point. Not every blind person uses screen readers on a desktop as well, there are plenty of handheld devices with screenreader support that just plain fail up against JS applications and/or JS heavy websites.
I appreciate this reply since it actually acknowledges the problem and proposes a path to a solution. I don’t know Angular very well to understand how it handles accessibility, but I do know that plenty of people are having issues with React components using non-standard devices.
ARIA depends on DOM attributes, and browser hooks/events looking for ARIA functionality are one of various contributing reasons for slow DOM parsing. So when people start chasing 60fps and native performance in their mobile apps, and complaining about legacy code being slow… those complaints often inadvertently include accessibility support; and accessibility gets lost when they rewrite the view layer from scratch.
This isn’t just a critique of React, but also of Famo.us, React Native, and various other libraries that bypass traditional DOM building/parsing; and look for super-optimized approaches. Of course, when those libraries mature to the point of adding accessibility support, they’ll find the problem domain is precisely as big as ARIA, and when they try to add it in, everything will bloat and slow down, and they’ll be right back where they started.
As for accessibility packages, the one’s I’ve personally been working on and will be including in the Clinical track include:
We have chriswessels:hammer for mobile multitouch, and clinical:keybindings package for hotkey, macro, and accessibility device support. clinical:audio-click is there for audio/tactile feedback for blind users. And leap-ui-progress-circle package for sign-language/gesture recognition systems, neural interfaces, and other low-resolution haptic devices.
I’ve got both the leap-ui-progress-circle and kevohagan:leapmotion packages on the roadmap to be migrated over to the clinical namespace for accessibility support and clean-room/surgical environments. Ergonomically, the ChecklistManifesto Todo app will go from multitouch-on-mobile to keybindings-on-desktop to gesture-on-videowall. Fun stuff!
Recently, I’ve been fielding a lot of NLP requests for voice recognition, voice transcription, and text-to-voice. Not sure how we’re going to handle that.
Exactly. This is an important point. The question then, becomes how to add the ARIA labels. So with Angular, it becomes sort of a drop-in library addition. With Blaze and React, one has to build up the labels by hand or do DOM patching of some sort. Or somebody needs to write an ARIA support package.
BTW, I’ve just checked my Meteor website with VoiceOver (screen reader on OS X) and it worked fine with me doing virtually nothing to make it accessible. The only thing that could be improved is having screen reader react properly when the route is changed (currently VoiceOver selection just stays where it was before and doesn’t announce that the content has changed on the page, but it still was possible to navigate new content and hear it).
If its not in the DOM to some extent isn’t it not possible to see it? Doesn’t the blind person have the same experience as an abled person for the most part? I know there are edge cases but everything I want my users to see is in the DOM.
I’m all for progressive enhancement and accessibility but I think it is more to do with picking your target audience. Roller Coasters have height restrictions for a reason. Yes they could make the ride slower, or build dedicated seats for smaller sized people but they would cost time and money.
Maybe my Instagram clone isn’t targeting the users of devices without a graphic interface.
Accessibility is more than just adding ARIA attributes, although that is an important part of it.
A big part of the task is simply making sure that your website can be used 100% from the keyboard. This is true even on mobile devices, where various screen reader apps operate by simulating TAB and ENTER key presses.
The best approach IMHO is to choose a widget library that has good accessibility support, and then have all user interactions go through widgets. This is (mostly) independent of how your DOM is rendered (Blaze, React, etc.)
So far I’ve been using Polymer, which is not perfect and has it’s challenges but at least they try to get it right.
Part of the problem that I am seeing is that developers of widget libraries don’t see accessibility as their problem, and think that it’s something that application developers should have to address when creating their DOM.
You can see an example of this attitude in this thread about Semantic UI, which is in most respects is quite a lovely library. Their opinion is that since all they do is style the DOM, not create it, they shouldn’t be responsible for updating all of the ARIA attributes when the DOM changes state.
The problem with this view is that supporting ARIA properly, in a way that provides a really polished and seamless experience for a blind user, is a complex task even for simple widgets, let alone things like menus and dialogs. It’s simply not possible for the average app developer to get it right without a lot of testing and iteration. In general, only the authors of widget library have the time and expertise to do all of this work, and it’s unreasonable to expect application developers to have to do it.
(One recommendation I’ve seen is to use a 3rd-party library that only provides the ARIA support, not visuals, and then use that in conjunction with the widget library that only provides visuals. However, I think this still creates too many opportunities to make mistakes on behalf of the app developer.)