Hi everyone and welcome to accessibility talks! Accessibility talks is a monthly
virtual meetup where we come together to discuss topics around all things website
accessibility. I am your host Carie Fisher and each month we feature a guest
speaker who will present an in-depth accessibility topic to the group.
After that we're going to have some time for questions and discuss. So you might be
joining us today to hear Scott Vinkle since he's our guest speaker.
He's going to be talking today about creating accessible React apps.
Scott is front-end developer and a website accessibility advocate at
Shopify where he works with his teammates to make Shopify products more
usable by a variety of people. Scott has been active in the accessibility
community since 2011 and as acted with many groups including the accessibility
project, the a11y tour (that just happened), CodePen Ottawa, and many, many others.
We're all just exhausted thinking about all the things you do - but welcome Scott!
We're glad to have you today! Thank you. Thanks so much for having me.
So here we go. Ok so hello everyone thanks again Carie for the introduction
my name is Scott Vinkel and I am indeed a front-end developer and web
accessibility advocate at Shopify. You can find me on Twitter, Github and pretty
much everything else at as "svinkle". So today I'm going to help answer the
question: can React apps be accessible? So it seems like there's a bit of a reserve
or hesitation when considering building an app with a newer technology like
React. Oftentimes folks may feel like these types of apps are difficult or
perhaps impossible to be made accessible by the very nature of them relying so
heavily on JavaScript. Well I wanted to get this right of the way real quick and
to the answer the question: Yes! React apps can absolutely be made to be
accessible for people with disabilities. So today I'm here to share some tips
that I've found and help with this. So for the agenda I'm gonna start out with
a few high-level notes when and if you're first getting started with
creating React apps. We will look at how to set the page title,
we'll review how to create a live announcements component, we'll explore
how to manage keyword focus between components and when loading new pages.
We'll take a brief look at React's accessibility linter which comes with
each new app. We'll spotlight a new ish feature with react fragments. I'll share
some thoughts on writing semantic HTML within React components and lastly I'll
end up going through a small demo app that I created to help
illustrate each point. So a few things to watch for when first starting to develop
with React. These things took me a little bit by surprise at first and I had to
get used to writing code this way but it wasn't so long before I got used to it.
And if you do make mistake and write something incorrectly you'll get a
friendly warning in your browser dev tools console with tips on how to fix it.
So when it comes to writing HTML attributes in React components they need
to be written in camelcase style. So this means that when an attribute name is
made up of two words the second word in the attribute must start with a capital letter.
So for example the attributes tab index needs to be written
as tab index with the capital "I", the attribute content editable needs to be
written as content editable with capital "E" and the other example here max length
needs to be written as max length with a capital "L". And it's worth noting that
the area and data attributes are exempt from this rule. There are a few reserved
words which come into conflict when writing HTML attributes within your
React components. For example, the reserved word "for" is used in HTML
when pairing a label with an input element. In JavaScript "for" is used to loop
through items using an index until a specified condition evaluates to false.
So for the for attribute this needs to be written as "htmlFor". And another example
here is the reserved word "class" which is you
in HTML to allow CSS and JavaScript to select and access specific elements via
the class selector. In JavaScript it's used to create a class declaration.
So when adding a class to an element this needs to be written as "className". And in
HTML5 there are a few elements which no longer require the closing tag as a one
student in a XHTML, but coming back to React in JSX which is a subset of
JavaScript to use React components. Excuse me, to write to React components
these elements require the self closing tag, self closing forward slash. So for
example here on the screen there is the image the meta and the input elements
and each of these I'll require once again the closing forward slash.
So let's look take a look at how to set a page title. So first of all why bother setting
the page title contents? Well there's a few reasons why you'd want to do this.
For one, it updates the content in the browser tab so sighted users have a
better understanding of where they are in the app. Two, it helps to increase
search engine optimization so in something like google comes along and
indexes your app it'll have that information. And the page title content
is often the first bit of information announced by screen readers so users of
assistive technology will have a better understanding of their current place in the app.
So how do I do this in react?
Well the simplest method that I found while do my research was to set the
title using the JavaScript "document.title" global property. So on the screen
here is a function called "componentDidMount" this is a React lifecycle method.
The code within this function executes when the component is loaded onto the
screen and the single line within this function is using "document.title" to
study string value of "my page title". So when this component loads the page title
will be set to this value. It's also worth noting that this is not
specific to or unique to React, this method can be used
in any JavaScript based application or website. So I felt like it would be worth
mentioning that there are other pre-existing components that other
developers have made. These components can be included in your project via NPM.
So for example the first one here is called React "DocumentTitle" and it can
be used by wrapping your content with a document title component then you would
add a title prop and set its value to the desired page title. The other one
here is called React "Helmet" and it is used by creating a helmet component.
Within this you can set anything you'd like that it would normally appear in
the head section of the page. So for example setting the character set you
can set the page title here or you can even include a page specific CSS
document. I also think it's worth mentioning that this component itself is
created by the NFL, so that's kind of an interesting little tidbit if you're into the NFL.
Okay so now let's take a look at a complete live announcements
component. So the idea is sometimes when you're working with a single page app
you might request data from external data source. For people who rely on
assistive technology it's a good idea to announce when and if the data request
was successful or not. And if it was successful how many items
are now displayed on the on the screen as a result. So let's take
a look at how to create a live announcements component. So here we have
the Announcements component in its entirety. The first thing here is to import React
from React and then we create the class definition with class
"Announcements extends React.Component" and within this class we have a single render method
with a return statement. And this simply returns a div element. So the div element
here features the ARIA live attribute with its value set to polite. Now this
means that assistive technology will wait until other messages are finished
being announced and then this content within the div will be read aloud.
The div also features the ARIA atomic attribute which ensures that all content
not just updated or changed contents will be announced. Within the div is a
single line that says "this.props.message" and which is wrapped
in the curly braces. This will output the message text when it's passed to the
announcements component. And finally we export the announcements components so
they can be used elsewhere in the app. So now that we have the component written
and available how do we actually use it? To start, in a parent component which
we'll call the announcements component. We'll create a new state property, we'll
call this property message and set its value to "null" just for now. So on the
screen here there's a "this.state" object declaration and inside this
object is a property called message with its default value set to null. Next at
the point in your app when you receive your data either successfully or
if things didn't work out as expected, we'll set the contents of the message
property. To do so you call the "this.setState" function and pass in an object
parameter. So this object will feature the message property we created earlier
with its value set to the string of the text we want to announce. And lastly we will
include the announcements component within the parent component, in order to
send it the message text from the states to the announcements component we use a prop.
The prop on the screen here is called message with its value being set to
whatever is currently in the message state property.
So when this component loads, the message will be announced by a screen reader and
the person using the app will be informed of the current state message.
So like with setting to page title there are other pre-existing components for
creating live regions, but I thought will be worth mentioning. So for example the
first one on the screen here is called react ARIA live and it requires a live
announcer component to be added to your template. Then within this there is a
live message component which takes the same message prop as described before
along with the ARIA live attribute. Also within the live announcer components is
your content that would be dynamically updated based on some event. And the
other component I found while doing some research about this is is one called
React a11y announcer and it's literally the same thing that I came up with earlier
which I described in the previous slides. So both of those are available if you're
interested in checking that out. Okay so moving on to the concept of focus
management. So well planned focus management is critical in creating
a successful and comfortable user experience, especially for highly dynamic
or single page apps. What I mean by focus management is moving the keyword cursor
from one place to another in order to assist the person on the other side of
the screen and moving along with the intended flow of the app. So let's take a
look at a couple examples. First thing we need to do is select an element to send
focus to - so how do we do this in React? Well it can be kind of helpful to think
about how you might be how you might be used to selecting an element with
something like jQuery. So on the screen here is an example of the jQuery dollar
selector, cashing a reference to the loading message elements in a variable
called loading message. And then somewhere else in your app you could use
this variable and call its focus method to set keyboard focus directly on
to this element. In React, the concept is kind of the same but how we arrive
there is a little bit different. In order to select an element the "React way" and
I'm using air quotes that you probably can't see, we create what's called a
function ref, or a "ref" for short. The ref is a prop that is set on the
elements we want to reference elsewhere in the component. So as an example what's
on the screen here is a plain div element. Within the div is the phrase
"loading" so this is probably meant to be displayed when the app isn't in some
sort of loading state. The div features a prop called ref and this ref is being
assigned a regular ES6 styled function. The function is being passed a parameter
called loading message and within the function is a single assignment
statement of "this.loadingMessage" equals loading message. This sets the ref
of the div to a class property called "this.loadingMessage". So now that we
have this class property we can use it elsewhere in our app. So in order to use
the ref that we just created we can use the "componentdidMount" lifecycle method
once again and then call the focus method on the ref element. On the screen
here is the "componentdidMount" method and within this is a single line
which reads "this.loadingMessage.focus". And when this component loads
the keyboard focus indicator will be sent automatically to this element which
will then announce its text content loading. So there's another important
example of focus management within React apps and that it is adjusting keyboard
focus when moving from page to page. So why exactly do we need to do this?
For one when using React routers link component new pages are inserted into
React's virtual dom without reloading the browser. As a
result, pages are perceived to load very quickly but people who depend on
assistive technology such as a screen reader might be left in an unpredictable
state. So how do we go overcome this issue? Coming back to the ref concept
one path we can take is to resolve this is to create a ref on the
outermost container element and use that
ref to shift focus to the page. So the idea is when a new page loads into view,
focus is sent to the top of the page and from there the user can navigate forward
from this point and discover content in the same manner as if a full page reload
had taken place. So for example on the screen there's a wrapper div element
which holds all of the page content including the header and footer, etc.
On the div there's a ref with its function assignment. With this function
we are passing in the parameter "contentsContainer" and assigning it to the class
property "this.contentContainer". Also on this div is a tabIndex attribute
with its value set to minus 1. So this ensures that the div will be able to
programmatically receive focus, but it will not be added to the natural focus
order of elements. And the other attribute here on this div is an
ARIA labeled by with its value set to the ID of the page heading. And this helps to
give extra contents of where the user currently is by announcing the page
heading content when the div receives focus. So how do we use this ref?
Again, it's the same idea we can use the ref within the "componentDidMount" lifecycle
method and then call the focus method on their ref class property. So when this
page loads the keyboard focus indicator will be sent to the container div
element and then the user can continue on with content discovery from that point.
So now let's talk about a newish feature in React the concept of
fragments. So what are fragments and why should we use them and more specifically
how do they help with accessibility of our apps? So let's answer that question.
So fragments let you group a list of elements or child components together
without adding extra nodes to the dom. Since React component templates must be
wrapped with an element in order to be returned within the render method
oftentimes developers will just wrap all the elements with a div. So this works
but if you're not careful this might also lead to invalid HTML. With fragments
we can now wrap templates with a fragment element. When the component is
rendered the fragment element itself is not sent to the dom, rendering only the
HTML required to properly output your content. So for example the code snippet
here on the screen features a render method with a return statement. Within
this is a div element which is wrapping some table cells TD elements with the
word "hello" in one cell in the word "world" in the other cell. So I think it's safe
to say that this component is meant to be a child of some other data table
component. So wrapping template code like this with a div it is very common but if
you were to wrap table content with elements here like so
well it would result in an invalid HTML being generated sent to the browser.
Divs are not valid child elements of table rows or TR elements. So that begs
the question how do we meet React's requirements of wrapping content with a
single element without generating invalid HTML? And normally this is the
point of my talk where I ask people to guest see what they say but I think I'll
skip that part for now since I can't see anyone. I'm moving on, yeah someone
probably guessed it - with a fragment! So now the code's that up on
the screen features a fragment element which is wrapping the TD element table
cells. So with this we can check out how the generated markup is going to look.
And there we go that's the result and that looks much better.
It's semantic, embedded HTML with no extra wrapper elements that looks really nice.
So moving on we have the concept of the React accessibility linter. Now React has
a linter which is prepackaged with each app. As a general notes a code linter is
a handy tool which helps to ensure clean code or code standards as determined by
team or an individual. In other words, they'll let you know automatically when
something's not quite right. Let's take a look at a few ways we can use the linter
to help ensure a more accessible React app. So the linter in question is called
"eslint-plugin-JSX-a11y" and it comes with each app
created with the create React app utility. So by default without any setup
our configuration on your part the lender outputs errors found to the
browser dev tools console. So for example on the screen here is an image with
a valid source attribute but it's missing its alt attribute. So as some
folks might know, if a screen reader comes into contact with this image it's
actually going to announce the source value instead of you know anything
useful that might appear in an alt attribute. So below this is a screenshot
of the Chrome dev tools console with the output image elements must have an alt
prop either with meaningful text from an empty string for decorative images.
I think that's pretty handy.
Outputting errors to the console like that is pretty helpful, but I think this
would be even better if these areas were displayed directly in my editor while
I'm writing code. So on this screen here is a screenshot of my Atom
editor outputting in an accessibility error within my code. It's the same
error as in the console in the previous slide so let's see how we can set this
up. First we need to install the ES lint plugin for your editor.
This is usually done within the editor as part of the editor package manager
and I've got some links here for the more popular editors these days.
The names of the plugins include linter-ESlint for Atom, sublimelinter-
contrib for sublime text, and ESlint for vs code.
Next we need to install the ES lint and ES lint plugin JSX a11y packages from npm.
You would accomplish this by opening up your terminal application, changing to
your to your app directory and then typing
"npm install eslint eslint - plugin - JSX - a11 y - - save - dev". This command will install these
utilities only for your current project as each project you work on could have
different configuration. And the last thing to do is to update or create one
if it doesn't exist your projects es lint RC file. In the plugins section of
this file you would add JSX - a 11 y. What this does is it loads the
accessibility plug-in for use with your editors es lens plugin. And then in the
extend section of this file you would add plugin : JSX - a 11 Y forward slash recommended.
And this loads the default recommended rules
for the plugin to test with to test recode against and I found that the
default rules are pretty pretty good. So after all this
is done all you have to do is restart your editor and you should see some
errors come up and you've got some accessibility issues in your code.
I think that's pretty cool. The last thing I want to discuss is writing HTML in React.
In the past I've been asked a very broad open-ended question of how
accessible is React? This was coming from the knowledge that other frameworks or
libraries had great difficulty when it came to accessibility as a result of the
framework team providing third-party user interfaces and components. In other
words if something wasn't successful there wasn't a whole, there wasn't really
a great chance of it actually being fixed as it relied on the third-party team.
So on this slide is a relevant quote from Heydon Pickering I feel it's
relevant and it reads: React code doesn't have doesn't have to be inaccessible any
more than hip-hop has to be misogynist. And I believe this to be true and it's
actually a nice segue to my next point. So what I've found is that since React
uses ES6 classes and standard HTML markup within its templates to create and
export, and to create and export components, it's up to you the developer
an app author to continue to write valid semantic HTML. With the exception of
course of using third-party modules from NPM it's all to you. The library itself
doesn't force you to use something that someone else created, thus, lowering the
risk of creating an inaccessible product. In other words, if there are any
accessibility issues it's your fault. And I think this is actually a really good
thing. Again it's up to you as the developer to fix these issues you don't
have to wait for a third-party developer group or a team to maybe get around to
fixing these things someday, you can do it yourself today. Okay so so now I'm
going to switch things over to my demo and yep I got Safari all loaded and
ready to go. Thanks for the reminder Scott. Let's see here, okay here we go. So
this is my app called TV-DB and for this demo portion what I like to do is go
through using a mouse and then I go through it again using just the keyboard
and then I'll go through it a third time using my voice over screen reader that I
have installed for Mac OS. And by the way Mac OS every installed Mac OS or iOS
comes with voiceover automatically. So let's see here. Okay so at the top of the
screen is like a logo that says TV DB below that says search TV DB for your
favorite TV shows. Okay I guess this looks like an input yep I can click on
that and it looks like an input that says your favorite show. Guess this is
just that's the search input beside that is a button that says make it so, I guess
that means submit? I know that's kind of confusing but anyway we'll go with it.
Below that there's a title that says check out what we're watching. Okay so
I'm running my mouse cursor over and it looks like these are links, I'm seeing
The Office, That 70s Show, Friends. Okay interesting and the very bottom
there's some footer information so I guess that's the bottom. Okay I think
what I'll do is I'll click on The Simpsons that's all my favorites and see
what happens. Oh okay so it just saw a flash of an
old-school television the snowy screen. I guess that was the loading screen and
we're here on The Simpsons landing page. What says Simpsons there's some summary
text it is the longest-running scripted show in US television history.
That's impressive. See details there is a table there's genre type animation Network and
the rating is 8.4 out of 10. That's pretty cool.
And there's a heading here that says more info with a couple links. Looks like
these links go to IMDB and I guess it says find out what YouTube has to offer
or available for The Simpsons. I guess that goes to YouTube okay.
Well that's pretty much it. A simple tiny little app. I guess clicking on this will
go back to the home page. Yep okay cool so now I'm gonna try and
go through with my keyboard and I'm gonna be hitting the tab key. So I see
there's a blue highlight around the banner link and I'm gonna keep on going.
Okay it looks pretty good I guess I can still see the highlight when I'm going
through each of these links and I'm at the footer already. Okay I'm gonna go
back up and try a search this time right. Oh yeah one of my favorites from when I
was a kid Star Trek. Okay I'll go over here and click this make it so button.
Now I'm gonna continue using my tab key. Let's see here...
I'm looking for my favorite which is the next-generation. There it is okay. So come
back here and click enter and there we go,
Star Trek The Next Generation it's pretty good show. Again there's a bunch
of summary text there's the details tab and these couple links here that go
somewhere, but I'd say that's that's looking pretty good.
Okay so now I'm going to come back here and turn on voiceover and see how things
might sound like. Voiceover on safari TV DB window visited link TV DB has
keyboard focus end off banner main. Heading level one three items search TV
DB for your favorite TV shows. Okay search your favorite show your favorite
show search text...Carie Fisher to everyone: any questions for Scott
Accessibility? React? That's awesome. Sorry everyone! Dennis Lembree to everyone : LOL
Okay it's all good. I'll keep going here. Guys keep on trucking. Voiceover on.
Make it so your favorite button. Heading level two: check out what we're
watching. Okay link image The Office. Carly Gerard : VoiceOver alerts work!
I'm going to go back and do a search here.
Your favorite show search text. Yes this is my talk why normally ask someone to
give me a show but I'm just gonna go ahead and put something in here.
What's a good show? Oh yeah I just finished this one up S-T-R-A-N-G-E-R things.
Stranger things selected okay make it so button loading search results for
stranger things group total results found four. Okay that's four. It's three
more than I expected but let's see what banner. This end of total results found
main heading level one: three items. Search results for stranger things.
Link image stranger things. Link image beyond stranger things. Link image places. Okay
link image 109 strange things. Link, link, link image stranger things. I assume this
is the let's try this. Loading stranger things. Group okay banner.
Visited link TV DB end of banner main. Heading level one: stranger things.
Heading level two: summary a love letter to the 80s classics that captivated the
generation stranger things is set in 1983 Indiana where a young boy vanishes
into thin air. Heading level two: details I'm always curious with the rating is.
Table two, columns three rows genre column one of two list genre three items column 2 of 2
bullet drama one of bullet fantasy two of three bullet science fiction 3 of 3.
End of 203 genre type scripted column 2 of 2 row three of three genre
rating column one of 2 8.8 column 2 of 2 out of 10. Okay it pointed.
Actually pretty good I think. Let's see what else is here. End of table heading.
Heading level 2: more info list two items roll it bullet one of two link checkout stranger
things on IMDB opens third party website a new window. Okay that's actually useful to have.
Bullet bullet two of two link find out what YouTube has available for
stranger things opens third party website a new window. Cool sounds pretty good.
End of list end of main voiceover off. So I think that the demo
serve demonstrates a lot of the some of the points that I brought up so there
was so focused management happening, there was the loading screen that was
announced when it showed up, there was the announcement of how many how many
items were on the screen after the search was completed. So yeah let's
head it off to see if there any questions but other than that, thank you very
much for watching! And if anyone has any questions they'd like to ask or if
they're watching this later on YouTube my DMs on Twitter are always open so you
can just ask away and I'll I'll get back to you eventually. Thank you. Thank you so much Scott.
Do you have a component example of the first focus management part?
Oh so yeah all of the examples that I
talked about in the in the talk are available in the app in the app itself
is all on Github. So I guess what I could do is just share these links while I'm
here. Yeah and we will share the links too when the video was posted in the body of
the content, below the video, we can have all the
links to Scott's presentation if he has them, to his social media account, his Github
account any links he talked about during his presentation. We will also have that, but since you guys are all
here you get a bonus that we can pop it into the chat winder here too. The follow up was I believe refs are about to be
depreciated in higher versions of React what is the best version of React that
is good for these awesome accessibility functionalities? Refs are about to be
deprecated in higher versions of React. Really? What is the best version of React?
I did not know the refs were going to be deprecated.
Yeah I honestly can't answer that question because I did not know
this this is something I'll have to add to my to my talk, interesting.
Well thank you for bringing that up.
Are there any more questions for Scott? I'd hate for there to just be one.
Did any questions come through on Twitter? Ha! No just people laughing at our voiceover shenanigans.
Do you have any...one thing that you could talk about to is maybe somebody is
joining us today that doesn't have a lot of accessibility experience. Maybe
they're new to accessibility. What would you recommend for them to do besides
some of the things you outlined today not specific to React. Are there
any groups that you would suggest or things you want to mention? Slack groups or
Twitter groups? Oh yeah absolutely. So I definitely always like to share the
a11yproject.com site - lots of good information there. Specifically I feel
like it's kind of geared towards beginning content. There is a
slack group that I always share and recommend. I don't have the link on me
right now or it's like web...oh there it is, I do have it. Okay so here's the link
to share and jump into the slack group and it's a whole bunch of accessibility
folks in there they're super nice people and really willing to help answer any
questions that you have. And also I will point out that on the a11yproject.com
site there is a listing of like meetups and people and like other groups to
follow. There's some really good resources from from all those Twitter
accounts so check that out as well.
I would second that Slack group, that's actually where Scott Vinkle and I and a lot of us met and kind of chat on the
side. You know people in there are chatting about obviously some really
heavy accessibility stuff but there's also lots of room for beginners or you
know side conversations or projects. I mean, there's really something for everyone there.
Since we've been chatting we have another question here from Andrew Macpherson.
Is there anything you found difficult to make accessible using React? Like, awkward workarounds which were hard to build.
And was it React's fault, or could React be improved to make it easier?
That's a good question because I have found a few
things where depending how the components are architected or depending
on like other third party things, you could come into some
situations where it's not so easy to implement the things that I suggest here.
Is it React's fault? Mm-hmm not really, but again if we're using React there is I
guess that's sort of that risk involved right. And if you're not building from
the get-go with accessibility in mind you could veer off into this other half
that could lead you down towards some some issues. Yeah so I'd say if you can
keep things simple and like fairly linear good. If you go and make some
things that are really accessible well yeah if you run into any odd situations
feel free to DM me or ask me a question on Twitter and I'll have a look for you.
This is a chicken and egg situation: which is really at fault? Maybe we don't necessarily have to blame anything or anyone, but just work to make it better.
We have a follow-up question here: How well does React work with higher order ARIA?
Things like aria-expanded, aria-owns, aria-controls?
So the things with that is in the slides I mention that in your component you are pretty much still
writing HTML right. So when it comes to things like referencing other elements
for something like ARIA owns or ARIA controls those things reference the idea
of some other elements in the component right. So in that case it can be a little
a little bit extra work to try and
get that ref from one component to the other, but if you know the ID and
it can just hard code it that's potentially an option, then things should
be fine right. So again with anything else that you're creating definitely
test and make sure things are all good and yeah that's why I would say about
that. That's a good question though and I don't think I've really tested that too
much, but I will be soon in my my work coming up with your Shopify, getting into
Polaris. Yeah we should mention too that
Scott is on accessibility React world tour. Is this stop four out of eight?
This is actually four of seven.
Yeah that's a good point. Just a comment here from Dennis.
React (and all SPAs) break the regular web page loading process so some of it is indeed its fault.
So we are putting some blame on to React.
Look like we now have a link here for stream references being depreciated, but not function.
Oh that's right ,that's right. So there's a difference there there's the original
ref prop and then there's what's called the function ref which is what I was
using in my in my talk. The function ref is like the new ref way to do things.
So that's a good point and thanks Andrew. And yeah and he follows up with a question:
What other tools do you recommend for live a11y testing, e.g. screen readers or low/impaired vision, etc.
The equivalent perhaps of cross browser testing in the accessibility world?
Yeah so the equivalent of cross-browser testing is
basically cross-browser testing with the addition of screen readers. So basically
what you would like to do is if you're testing on Mac OS the typical
combination is Safari with voiceover. On Windows you might be what to test JAWS
with Firefox or Internet Explorer and then the other combo is NVDA typically
with Firefox. And along the same lines you definitely still want to test on
mobile devices so you would also want to test on iOS Safari with voiceover and
Android you want to test with Chrome and Talkback. So other other tools?
There's lots of tools out there like automated testing tools there's aXe, there's
what's the new one in Chrome? Lighthouse. Lighthouse tools is actually
really good. I think that uses aXe actually, but yeah there's lots of stuff
out there. And we can list some of those resources for tools for again for
some people who may be coming to us from the React world
and want to know a little bit more about accessibility.
We are kind of running out of time at the end of the hour here, so asked if we wanted
to have any more questions about React, accessibility, Canada in general.
So we got another one follow-up from Andrew:
Do you need hardware for that testing, or can you use virtual machines or SaaS services?
So my setup here is I have a MacBook Pro and for testing other operating systems
and screen readers. I do use virtual machines specifically the one I use is
what's called VMware fusion. Although excuse me in the past I've also used
what's that free one VirtualBox that also works really well in addition to that.
I also have boot cam set up with Windows 10
and I have even more the same screen readers and browsers installed
there just for extra testing. So as far as hardware is concerned if you've got
any desktop or laptop computer if you have like a mobile device iOS or Android
that's that's pretty much all you really need to get started I would say.
There's lots of other pieces of hardware that people with disabilities use like
Braille readers or puff devices but for the most part if you have these
things you're good to go just to get started. Dennis is following up:
Can you make the PC keyboard keys work with the VMs?! I haven't really had any issues with that.
I think I know what your what you're speaking towards Dennis. I so when I'm using my Mac keyboard it's
a full-on full-size keyboard and I have the virtual machine full screen and I
don't know I've never experienced any real issues. I think you can remap some
keys with JAWS or NVDA because someone I think by default they
use the insert key which not everyone has available. I think you can really map
that to the caps lock key as an option, if that's what you're referring to Dennis.
I'm not sure but yea. And it looks like Andrew Macpherson is following up:
We all have our kind of different setups for testing, he was just saying
Screen reader audio in virtual machines can be glitchy or laggy sometimes, may need to tweak audio settings in virtualbox to make it bearable.
I think that's true of all things run on a virtual machine.
But he said if he suggests that maybe needing to tweak the audio settings and
VirtualBox to make it bearable again. And again, we can link to some of these resources that we
use and it probably should be pointed out too for anyone who's new to
accessibility that these are suggestions there are a thousand tools out there,
but it should be noted that automatic testing is not
100% foolproof so you know you need to do manual testing and whole bunch of
other things, but just getting started.
Any questions? Anybody else? All right going once, going twice. Alright so thank
you again Scott for coming and talking about React and accessibility.
As a reminder again the video, links, any kind of resources where you can find Scott,
Twitter and other and github @svinke. A reminder that accessibility talks happens
each month and the topic changes for month and the speaker changes so
join us next month on March 28th at 12 p.m. More details follow,
but thank you again! Thank you!