How does Meteor handle accessibility? How do you justify a platform that just flat out doesn’t work when someone has disabled JavaScript?
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 that aren’t browsers at all - CLI clients, shell scripts, macros built into spreadsheets or other applications, that can perfectly happily make an HTTP request and parse a string of HTML but can’t necessarily spin up an entire javascript VM and query an entire DOM just to get the same information.
Devices which aren’t general-purpose computer systems, and hence may not be well-suited to running javascript efficiently - embedded devices, non-traditional (say, extremely slow but massively parallel) processors, etc.
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.
Devices that get delivered non-working code - errors in your JS, third-party tools or systems that get injected into your code (marketing teams do love their third-party analytics, remarketing, lead-tracking, etc systems, CMS users love cutting and pasting SurveyMonkey and other third-party Javascript widgets into pages, etc, etc, etc, all of which can throw JS errors and/or fuck up your javascript, especially when 90% of them are written assuming they’ll be injected into a static HTML page, not a dynamic client-side SPA).
Troops that are deployed overseas that have JS blocked in their browsers.
How do you justify Javascript at all as a language that doesn’t work when somebody has disabled it?
What would you suggest in this case, should Meteor be rewritten in PHP?
They are at work. If their employee disabled JS for them, they simply shouldn’t be using JS applications.
That said, during my army service I wasn’t allowed to do many things and it never stopped me from doing them. If American soldiers wish to use JS, they’ll find a way.
I have a friend who is blind, and even on a very old computer his screen reader handles all websites correctly, whether they use javascript or not. The trick is that the readers don’t read page source anymore, but instead view the generated DOM itself, so they basically see the website the same way we see it.
I agree that it still leaves the problem unsolved for other use cases (headless web scrapers, lightweight browsers etc.) though I think its reasonable to say that soon Javascript enabled will just become a requirement for browsing the web just as HTML parsing capability is required for 99.999% web content today (or do you think that all websites should still support WAP?).
The modern W3C standard you’re looking for is called WAI-ARIA. Support for ARIA is generally found in the Angular/Polymer/Webcomponents ecosystem, rather than the React ecosystem.
So could one say that the best way to build an accessible Meteor app is to use Angular?
Speaking of which, id love to have a short section in the Meteor Guide about accessibility. I wonder what would go in there. Perhaps a list of links to other good resources?
This is ridiculous. You’re not understanding the concept of accessibility. This is the argument against full-stack JavaScript applications in the first place and other platforms are looking at how to solve these issues.
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.
Another thing that could be worth thinking about is that Meteor might not be the best platform for all apps in the world. If your users aren’t able to run JavaScript on the client, then Meteor will probably never work for them, or at least not the 1.x series. So it might be worth considering other development environments.
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.
With Meteor, the content usually is in the DOM, unless you are doing something fancy with animations, etc. So if you add proper ARIA labels to your HTML, most screen readers will handle it just fine.
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 important but a lot of these platforms will have solutions and those developers targeting users of those platforms will be leading the way. Javascript is becoming much more prevalent, internet speeds are getting better with less drop outs, devices are getting more powerful, Flowrouter can provide SSR.
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.)
