4

There is a complicated application which is heavy in data processing and front end developers considering implementing the designs entirely with React JS.

As this tool is responsible entirely for delivering the interface that the user interacts with what pitfalls and concerns are there from an accessibility perspective? What should front end developers avoid (if anything)? What barriers could ReactJS put up in terms of accessibility if it's used incorrectly?

I'm asking because I'm aware that various base front end technology extensions can be a headache for SEO crawlers (James Shore describes it as a minor miracle that React doesn't mess up SEO here) and that there's actually little difference between a crawler and screen-reader (both are blind to styles, for example, and do much better with things like well formed HTML).

  • I don't know enough about how React JS works to fully answer the question. However, for a typical one-page app where content is dynamically generated, a blind user using a screen reader needs to be aware when a section's content refreshes for them. I believe an update of the URL (in which React handles?) ought to be sufficient. That and following the WAI-ARIA guidelines. – nightning Oct 8 '15 at 16:22
  • 1
    React is not quite the same as JS MVC frameworks such as Angular, because it is just the view layer - it allows you to consume JSON API data then renders HTML/JS components to visualise that data – Toni Leigh Oct 8 '15 at 16:25
  • My apologies for not understanding what React is. Then it seems like it's up to the developers to identify the HTML components with accurate ARIA Roles. Then, if possible, provide a summary for the visualization as the caption. – nightning Oct 8 '15 at 16:34
  • I am however here because I know that with tools such as React important things like accessibility can sometimes get lost in the 'shiny new toy' effect – Toni Leigh Oct 8 '15 at 17:27
2

It's not too different from other client-side frameworks

I've been doing quite a lot of development on React, on both web and native. I'm going to give this answer for the web, because React native has different accessibility concerns.

React brings a semantic, object-oriented approach to building UI's. Traditional web development involves building user interfaces from components like <div> and <span>, which then have to be composed in HTML, Javascript, and CSS into parts of your UI.

React allows you to build components that resemble actual logical or semantic parts of the application and UI, like <CommentWidget>, <Calendar>, or <FlightPath>. It also allows developers to bind behaviors and data flows and states to these components. As a result, I've found that UI's tend to be FAR better composed, reusable, modular, and readable with React than with any other framework I've used in the past (Angular, jQuery Node, etc).

This is especially true for data-rich apps, where UX components have a lot of dependencies and relationships with each other, like social networking, complex filtering or data analysis, or stock trading. In these applications, the need to ensure data integrity is far more important than the need to get pixel perfect presentation right.

How does this affect accessibility?

Ultimately, React renders its components into standard HTML components in the DOM, so in other words, it renders into HTML tags for you. As such, accessibility concerns are similar to those in other frameworks like Angular:

  • Web crawlers may have trouble reading page content if they are not javascript-friendly, because react pages usually (but not always) have most of their content rendered using client-side javascript.

  • URL management is no different from any other app. The developer can decide how to manage URL routes, and whether she wants one route per http page request, or a single-page style app where javascript pushes and pops routes into the URL. Page links can be static (e.g. <a> tags loaded with the page) or dynamic/javascript...this is no different from apps written with jQuery, etc.

  • Aria and other accessibility tags can also be rendered easily with React.

  • Future direction. In an indirect way, React may actually be better for future accessibility because the high composability of the UX facilitates the development of advanced widgets like voice recognition plugins, large-font rendering, etc. In React, styles are specified right next to the component logic, so for example it would be easy to have different "sight-challenged" or language settings for the site and have that propagate down into widgets who know how to render themselves within that accessibility context.

I'm not affiliated with Facebook, but I have to say that after looking at and using a large variety of frameworks in the past, I've found React to be exceptionally well designed for front-end development, especially for full-stack developers.

Keep in mind that the framework is still not yet mature, so caveats apply accordingly...the set of components is still limited, security implications haven't been fully thought out, and there may still be issues with client-side memory management, etc.

Also, the collocation of behavioral logic, styles, and rendering structure into a single JSX files presents some challenges for large team development since designers and developers may need to be adjusting the same file at the same time. There are good ways around this, and IMO the advantages of collocating components into one encapsulated file far outweigh the drawbacks.

  • as the wuestion specifies accessibility would you please expand on your third point? <strong>aria and other accessibility tags</strong> seems not enough, though less likely to provide an example from code, could your answer be more q-goal oriented – Jedi Commymullah Oct 14 '15 at 0:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.