spotifyovercastrssapple-podcasts

Accessibility in Elm

Guest Tessa Kelly walks us through some accessibility best practices and how to apply them in Elm.
June 21, 2021
#33

Transcript

[00:00:00]
Hello, Jeroen.
[00:00:01]
Hello, Dillon.
[00:00:02]
And I think we've got an Elm Radio First today, which is our first ever repeat guest.
[00:00:09]
We've got Tessa Kelly with us again today.
[00:00:12]
Hey, Tessa.
[00:00:13]
Hi.
[00:00:14]
Thanks for joining us.
[00:00:15]
Thanks for having me.
[00:00:16]
I'm excited to be here.
[00:00:17]
I'm excited to learn from you because I think we've got quite a bit of knowledge that we
[00:00:22]
can absorb from all of your experience with accessibility today.
[00:00:26]
So well, as we like to do, Jeroen, maybe we can start with a definition of accessibility.
[00:00:33]
I suspect it may get a little bit philosophical.
[00:00:35]
Yeah, I think so.
[00:00:37]
I tend to think of accessibility as being literally about access, being about making
[00:00:42]
sure that everybody has access to the information, the services, the employment, the educational
[00:00:49]
materials that are available on the internet and that are important for people to have
[00:00:53]
access to, not to define accessibility in terms of itself.
[00:00:57]
Yeah, no, I like that.
[00:01:00]
One thing I've been thinking about is, for example, if you are in a country that has
[00:01:08]
limited bandwidth for networks, if you're in the middle of Mumbai, they might have very
[00:01:14]
powerful cell towers, but they're being used so heavily that the bandwidth is just not
[00:01:21]
there if you're on a mobile device.
[00:01:23]
And if you're on a mobile device with a small screen, that could be a type of accessibility.
[00:01:28]
And if you have a low powered device.
[00:01:30]
Yes, I suppose there's a layer when you're talking about accessibility of the device
[00:01:36]
and the tools that you have that you're interacting with in order to access the information.
[00:01:41]
And then past that layer, there's the human piece.
[00:01:44]
There's the physical body.
[00:01:47]
What is your body able to do to interact with the devices that you have?
[00:01:52]
I think a lot of folks start thinking about accessibility in terms of vision problems,
[00:01:57]
in terms of blindness, impaired vision, color blindness, but there's many more things that
[00:02:03]
go beyond that.
[00:02:04]
Right.
[00:02:05]
Reduced motion is another one that people are starting to think about more these days.
[00:02:09]
Yes.
[00:02:10]
You mean in terms of avoiding animations that folks don't want to see?
[00:02:14]
Or do you mean in terms of the person themselves has reduced motion?
[00:02:18]
Yeah, I was thinking about the preferring fewer animations and the media query for prefers
[00:02:27]
reduced motion, that sort of thing.
[00:02:28]
But yeah, there are both.
[00:02:29]
Gotcha.
[00:02:30]
Yeah, so I guess there's just in a way an acknowledgement that the way you're accessing
[00:02:36]
a website is not necessarily going to be exactly the same as the way somebody else is accessing
[00:02:42]
the website.
[00:02:43]
Yeah, I think an acknowledgement and then beyond that, an explicit consideration and
[00:02:48]
design for the usage patterns that someone who's using that different access pattern
[00:02:52]
is going to require in order to be successful at using your site.
[00:02:56]
And not just successful, but happy to use your site.
[00:03:01]
Delighted perhaps?
[00:03:02]
I think delighted is the thing to go for, yes.
[00:03:05]
Yeah, right.
[00:03:06]
And this becomes a really interesting area too because then there's that ethos and elm
[00:03:11]
of hopefully we like delighting people with tools, but also hopefully making delightful
[00:03:18]
web experiences.
[00:03:20]
But then there's also this question of how can we leverage these awesome tools that we
[00:03:26]
have in elm like the type system to help with those things, to help remember to consider
[00:03:31]
these different types of users with different experiences.
[00:03:35]
Right, right.
[00:03:36]
And then separate from elm, I think that thinking in terms of developers, developers often think
[00:03:41]
in terms of user pain, like this will be a painful experience.
[00:03:46]
And then they also think in terms of their own pain, like I'm going to get a fancy keyboard
[00:03:50]
so that I don't develop pain.
[00:03:53]
And when you're talking about accessibility, I think another piece to consider is that
[00:03:56]
some of your users might be able to achieve a user flow as you've designed it, but they
[00:04:02]
might experience literal physical pain as a result of trying to use that flow the way
[00:04:07]
that you've designed it.
[00:04:09]
So if someone has RSI and it's an injury in the wrist that makes it hard for some folks
[00:04:16]
to type or use a mouse and it's quite common.
[00:04:20]
And I mean, I've only ever heard of developers having it, but I'm sure that many people have
[00:04:24]
it.
[00:04:25]
So you might have like literal physical pain, making it harder for you to use the physical
[00:04:30]
interfaces that are in your home.
[00:04:32]
Or you might have epilepsy triggered by flashing.
[00:04:35]
You might have migraines or nausea from screen color changes.
[00:04:41]
I think even before the delight that Elm can bring or the delight that a type system can
[00:04:46]
bring or the delight that a user interface can bring, there's a moment of don't hurt
[00:04:51]
people that I think is pretty important.
[00:04:53]
Like a Hippocratic oath for programmers.
[00:04:56]
Yes.
[00:04:57]
Yeah.
[00:04:58]
Wow.
[00:04:59]
That's a good consideration.
[00:05:00]
Yeah, I hadn't considered the physical pain element, but that's important if you can induce
[00:05:08]
pain with your website.
[00:05:11]
That's a major bug.
[00:05:12]
Yeah.
[00:05:13]
Usually I think about accessibility, about people not being able to do what is intended
[00:05:18]
to be done, to make possible.
[00:05:21]
But yeah, I didn't think about pain at all.
[00:05:24]
I know that some people have problems with, as you said, with the epilepsy.
[00:05:29]
Yeah.
[00:05:30]
That's not what I had in mind.
[00:05:32]
Definitely good to know that.
[00:05:33]
You link to this set of principles, Tessa, in your accessible HTML docs of the principles
[00:05:40]
of accessibility.
[00:05:42]
Do you think that those four principles are a good framework to frame your thinking on
[00:05:49]
this?
[00:05:50]
Yes.
[00:05:51]
I also think that they're really helpful to communicate with folks outside of engineering.
[00:05:55]
I think many people have a perception that accessibility is about adding the right ARIA
[00:06:00]
property, and that it's on the engineers and on the engineering side to make sure that
[00:06:05]
a site is accessible.
[00:06:06]
But if you start talking about the principles of making your site perceivable, operable,
[00:06:13]
understandable and robust, you realize that what you're talking about is users.
[00:06:17]
You're talking about users being able to do something.
[00:06:20]
You're talking about user stories, and user stories are clearly something that's coming
[00:06:25]
from product managers, from designers, from folks who are thinking about experiences.
[00:06:31]
Is it true that there are some legal implications for accessibility in websites as well?
[00:06:39]
For example, you're working in the education space at No Red Ink.
[00:06:43]
I think that if you have educational software and it's not accessible, that can actually
[00:06:50]
have legal implications.
[00:06:51]
I've heard of trials where, for example, you could even pull out automated accessibility
[00:06:59]
testing tools as evidence in a trial to show whether or not you were negligent in providing
[00:07:06]
an accessible website.
[00:07:08]
I think the requirements differ country to country, state to state.
[00:07:13]
And I think in law in general, a law that hasn't had litigation doesn't count.
[00:07:20]
You need the court system to operate before people will feel obligated to follow the law.
[00:07:26]
Because we work through precedents in at least the United States court system.
[00:07:31]
That's my impression.
[00:07:32]
So you're allowed to kill someone unless there is a jury saying, hey, you shouldn't.
[00:07:38]
It's habeas corpus.
[00:07:39]
You're allowed to kill somebody as long as nobody finds the body.
[00:07:42]
That's true.
[00:07:43]
You heard it here first.
[00:07:44]
Getting macrub here on Elm Radio.
[00:07:52]
Legal advice from Tessa.
[00:07:54]
To be clear, you should not take legal advice from me.
[00:07:58]
You should not kill people.
[00:07:59]
Oh, right.
[00:08:00]
Hand that.
[00:08:01]
Good point.
[00:08:02]
Right.
[00:08:03]
But there are legal reasons to make sure that your site is accessible.
[00:08:08]
There's good reasons to keep track of what you've done to make sure that your site is
[00:08:12]
accessible.
[00:08:13]
If you're organized and keeping records and doing regular audits, you're going to be in
[00:08:18]
a better position if there ever is a trial.
[00:08:21]
But again, based on what I just said about habeas corpus, probably you shouldn't talk
[00:08:26]
to an actual lawyer.
[00:08:27]
That seems fair.
[00:08:28]
I also think that thinking about trials is a very American centric point of view.
[00:08:35]
Well it just makes it more concrete that these things have happened maybe infrequently.
[00:08:42]
Not that that should be the motivation, but it's a concrete thing and it's increasingly
[00:08:48]
the expectation.
[00:08:50]
When I was getting into web development around 2012 or so, mobile first and responsive design
[00:08:58]
was this new thing.
[00:09:00]
It wasn't the norm.
[00:09:01]
If you had a 1024 by 768 dimensions that you tested on and that was all it worked on, that
[00:09:10]
was the norm.
[00:09:12]
I think that we're getting more to a place where you're expected to have accessibility
[00:09:17]
in a website.
[00:09:18]
We're not quite there yet.
[00:09:19]
We're not quite where we are with expecting responsive first, mobile first now.
[00:09:25]
But we're moving in that direction.
[00:09:27]
It's something that is a necessary skill.
[00:09:30]
But I am really under skilled there and need to learn more.
[00:09:36]
But I think we should all skill up there right now.
[00:09:40]
I think it's definitely part of what goes into building quality software.
[00:09:44]
If you think about the R in perceivable, operable, understandable, robust.
[00:09:50]
Robust means having tests and making sure that you're using up to date technology.
[00:09:56]
I think it is part of this larger conversation about what it means to build a good website.
[00:10:02]
But it is challenging because it does encompass all of these topics and tools.
[00:10:09]
It is a topic that feels overwhelming.
[00:10:12]
When you hear about accessibility, people talk about visual impairments.
[00:10:15]
You're able to focus through keyboards and to do everything with screen readers.
[00:10:22]
The more you hear about it, the more you hear about people with certain needs, certain problems.
[00:10:29]
It just feels like a never ending list.
[00:10:32]
In that sense, it feels overwhelming.
[00:10:35]
That said, for everything that you want to start improving, the most important part is
[00:10:41]
the first step.
[00:10:42]
I didn't do many steps in this regard.
[00:10:46]
I hope to learn from you here.
[00:10:49]
I feel like it's very hard to take this big list of a million possible accessibility things
[00:10:57]
you could do.
[00:10:59]
You look at all these possible ARIA attributes and you're like, am I supposed to use them?
[00:11:04]
Sometimes I hear people saying, if you're reaching for ARIA, it should be the last resort,
[00:11:08]
not the first resort because you should be using regions and things like that to make
[00:11:14]
things accessible without the help of ARIA when possible.
[00:11:19]
Same with building a mobile first site.
[00:11:23]
There are so many techniques.
[00:11:24]
If you just read about the techniques in the abstract, it's very difficult to know if you're
[00:11:28]
hitting the mark.
[00:11:30]
If you pull up an iPhone simulator or whatever mobile device simulator or open Chrome with
[00:11:37]
the little mobile dimensions tool, then you're like, oh, this page doesn't look quite right.
[00:11:45]
I've been wanting to do this for a long time and I just never did until just before recording,
[00:11:55]
I opened up VoiceOver, the built in Mac screen reader device, and I went through a few websites.
[00:12:02]
It was cool.
[00:12:04]
I was learning some of the hot keys and getting a sense for some of the navigation.
[00:12:10]
I feel like that's got to be the key to making more accessible experiences because, for example,
[00:12:15]
I went to a couple of my sites and I tried changing to a new page and I noticed that
[00:12:24]
it didn't read to let me know that the page had changed.
[00:12:27]
It wasn't aware of that.
[00:12:28]
That's something I've heard.
[00:12:30]
I know that Reach Router in React land and a few of these other routers have had a journey
[00:12:37]
where they lacked accessibility on single page page navigations and they had to figure
[00:12:43]
out the best practices and pave the way for that.
[00:12:46]
I think they've started using these Announce, what is it called?
[00:12:52]
Oh yeah, ARIA Live Region to create these page change announcers so that you can let
[00:12:58]
an assistive device know that the page has changed.
[00:13:02]
For example, if you open up a website that you maintain and try that, you're going to
[00:13:09]
be able to connect more with that experience and understand, maybe I'm not an expert on
[00:13:14]
using a screen reader, but I can tell there's a major shortcoming that I should fix there.
[00:13:19]
I think that's a great step.
[00:13:22]
Also I think believing that any step is a good step to take.
[00:13:27]
There's so much that you can do in web development in general, but you don't necessarily expect
[00:13:32]
yourself to be an expert in all the front end technologies, all of HTML, all of CSS,
[00:13:37]
all of Elm, all of JavaScript, all of it.
[00:13:41]
You focus on the problems that you're working on and you break them down into smaller pieces
[00:13:45]
so that they're manageable and not so scary and you work through them.
[00:13:50]
I think that the same thing has to apply to accessibility.
[00:13:54]
You won't make progress if you try to memorize everything in WCAG 2.1.
[00:13:59]
That's going to be really hard.
[00:14:01]
It's one step at a time.
[00:14:06]
As we talk about a lot on this podcast, it's all about feedback.
[00:14:10]
If you can get good feedback, then you can get good things based on that feedback.
[00:14:15]
I would imagine the same is true for accessibility.
[00:14:19]
There's a limit to what you can do with automated tests.
[00:14:25]
What's been your experience with things like Axe and these other automated accessibility
[00:14:29]
tests?
[00:14:30]
What do you get from those tools?
[00:14:31]
I think they're helpful.
[00:14:32]
I don't think that they're a replacement for opening voiceover yourself, but they're definitely
[00:14:37]
helpful and having them as part of your testing just baked in is great.
[00:14:44]
In particular, for something like messing up heading order, so you have an H1 and then
[00:14:48]
all of a sudden you've done something and they're out of order.
[00:14:52]
That's a very easy mistake to make if you're changing the styles of your headings and you're
[00:14:56]
not going to see it just by looking at your screen.
[00:14:59]
It's really helpful to have tooling in place that's going to tell you, you made a mistake
[00:15:04]
here.
[00:15:05]
It's just like what you said about the feedback.
[00:15:06]
Tooling that tells you where you made the mistake is really helpful.
[00:15:11]
I find it really helpful to actually...
[00:15:16]
If there's a rule, there shouldn't be multiple H1s in the page or that sort of thing.
[00:15:23]
I find it really helpful to remember rules that we're supposed to follow if I understand
[00:15:28]
what happens as a result of not following that rule.
[00:15:32]
Why don't we take that example?
[00:15:34]
Can you tell us what would actually happen if we were using a screen reader?
[00:15:38]
How would the experience differ if we had problematic header hierarchy?
[00:15:44]
I think a screen reader is going to try to make the page navigable to you without needing
[00:15:50]
to go through every item on the page.
[00:15:53]
Your headings are like in an outline for a document or anything like that, structured
[00:15:59]
content, like an outline for a document or structured content of any type, you want to
[00:16:05]
be able to provide to that user places where they can find their point of interest quickly
[00:16:10]
and easily.
[00:16:11]
The screen reader will use those headings to make an outline of your site so that the
[00:16:16]
user can easily jump to the pieces of the site that they care about so they're not forced
[00:16:21]
to go through every single item and read through every single item, read all your paragraphs
[00:16:26]
and paragraphs of brilliantly written content.
[00:16:29]
But my goodness, so long.
[00:16:32]
I was playing around with voiceover on some sites and I was trying to learn some of the
[00:16:38]
shortcuts and I noticed there's a shortcut for next heading, but I think that just goes
[00:16:45]
to any heading.
[00:16:46]
It will just skip to any heading.
[00:16:50]
How would somebody using a screen reader or using voiceover in particular navigate, how
[00:16:55]
would they skip over H3 headings and go to the next H2?
[00:16:59]
So we are kind of getting into, I've probably got about five hours of straight voiceover
[00:17:05]
time total.
[00:17:06]
So if you picture my answers as being delivered to you by someone who has used a computer
[00:17:10]
for five hours, not very good.
[00:17:15]
I think that the router, there's a view that you can access that gives you more of an outline,
[00:17:21]
but I don't remember what the shortcut is for that.
[00:17:24]
Got it.
[00:17:25]
Okay.
[00:17:26]
Now that makes sense.
[00:17:27]
Yeah.
[00:17:28]
So somebody who's very well versed in using assistive technology would be comfortable
[00:17:33]
just flipping between hierarchy mode and read me the paragraphs mode or something.
[00:17:39]
That's my understanding.
[00:17:40]
As an inexperienced user, my tendency is to just go straight through because it's easier
[00:17:47]
for me.
[00:17:48]
And I'm usually, I get to a particular section, start voiceover and then only look at the
[00:17:52]
particular section.
[00:17:53]
So I'm not to the point of using voiceover for everything.
[00:17:57]
Right.
[00:17:58]
So another one I see is this like skip to main content.
[00:18:02]
And I'm like a little fuzzy on this because I see like a lot of, you know, if you go to
[00:18:07]
GitHub or Google and just hit tab, as soon as you run a search or open a GitHub page,
[00:18:14]
then you're going to see this text appear that says skip to main content.
[00:18:19]
Is that a best practice?
[00:18:20]
And like, how do you create that?
[00:18:23]
Yes.
[00:18:24]
I think the skip to main content links are excellent for primarily keyboard users.
[00:18:31]
I think that the user that you're trying to help with a skip link is someone who prefers
[00:18:36]
not to switch to the mouse, but is using the screen.
[00:18:39]
So maybe somebody who has a really ergonomic keyboard, but due to a risk situation of some
[00:18:45]
kind doesn't want to be doing those transfers to and from the mouse.
[00:18:50]
And it's a best practice because you can go directly to the main content without having
[00:18:55]
to hit tab, which again might be painful for a user, physically painful to get all the
[00:18:59]
way to the main section.
[00:19:02]
The way to create the link is you hide it until there's a keyboard event.
[00:19:07]
And then if the link is focused, you show it.
[00:19:10]
Now is that like in an L map, would that be in the model, whether there's been keyboard
[00:19:15]
input yet or?
[00:19:16]
I suppose you could show it just if it's focused.
[00:19:20]
So if you're on the URL bar and you hit tab, then it would come into focus and then show,
[00:19:26]
but you can keep track on the model of whether there's been keyboard, what the last input
[00:19:31]
type was.
[00:19:32]
If you're wanting to hide your focus rings, although I think focus rings are pretty okay.
[00:19:39]
You can just show them.
[00:19:40]
People know that they're there.
[00:19:41]
You don't have to hide them.
[00:19:44]
I remember that I had to hide one at one of my previous companies because it didn't look
[00:19:50]
as great as on the designs.
[00:19:52]
I fought back against it, but I caved in and I feel really bad about that now, which is
[00:19:57]
good for the next time.
[00:20:00]
So these like built in features that are intended to help with accessibility in the browser.
[00:20:06]
I mean that seems like ideal to me.
[00:20:09]
If the browser can have defaults that, you know, assuming you don't override them will
[00:20:14]
help with accessibility.
[00:20:16]
Like I'm curious with like skip to main content, if that's a best practice, why is that not
[00:20:23]
built in as a standard?
[00:20:25]
Because if you have like a main region, you can have like a main tag in your HTML content,
[00:20:31]
which is generally a best practice as well.
[00:20:34]
So why wouldn't that be built in to browsers or assistive tools?
[00:20:38]
I don't know.
[00:20:39]
I'm not sure if you have thoughts on that, but maybe it will be.
[00:20:41]
I mean, there's a lot of stuff that people would like to have, but don't.
[00:20:48]
I also think adding a skip link, it's not that hard.
[00:20:51]
I mean, compared to a lot of the other features that a person is likely to do, pretty straightforward.
[00:20:57]
So I would recommend adding it if you've got, you know, a couple of hours, just try.
[00:21:03]
Yeah.
[00:21:04]
No, it's, I think the thing that makes me uncomfortable is just not knowing exactly,
[00:21:08]
like if I could get some sort of checklist, like run a tool, and I guess if you run like
[00:21:12]
axe, it's going to tell you, Hey, you don't have a skip link and you should add one.
[00:21:16]
So that's great.
[00:21:17]
Like I'll, I'll, like it's easy enough to just like let the tool give me a checklist
[00:21:21]
and run it.
[00:21:22]
Well, there is a checklist in the sense of the standards.
[00:21:26]
Like you have WCAG 2.1, you can go through all of those items and consider them and check
[00:21:32]
them off for yourself.
[00:21:33]
There's also, there's templates that exist for if you're selling to, I guess the government
[00:21:38]
in the US that would help you to write up, write up your alignment in terms of a checklist,
[00:21:44]
like VPAT, VPATs are those documents.
[00:21:48]
But ultimately I think because you're talking about users, I don't think a checklist is,
[00:21:54]
is really going to be enough.
[00:21:55]
I think that there's a step beyond the checklist that you're going to have to do.
[00:21:58]
Right.
[00:21:59]
Do you think it's sufficient to run the tests yourself?
[00:22:01]
Like try to go through the flow that you designed by yourself using a screen reader, using just
[00:22:07]
a keyword, or do you really recommend to invite people who are used to those workflows to
[00:22:14]
those flows?
[00:22:15]
I think you should probably try to get real user testing whenever possible.
[00:22:19]
And then I also think that you should design explicitly for the user groups that you're
[00:22:24]
trying to support.
[00:22:25]
I don't think replicating the behavior you want for point and click users for other user
[00:22:31]
groups is going to be as successful as trying to design explicitly for, for every user pattern
[00:22:38]
that you're trying to support.
[00:22:39]
Like with the skip link behavior, if you don't have the skip link, your user can still accomplish
[00:22:43]
what they're trying to do.
[00:22:44]
They just have to hit tab for the rest of their lives until they get to the content
[00:22:49]
that they want or use command F or something like that.
[00:22:52]
And then if you have like a draggable interface, it's going to be pretty hard to replicate
[00:22:55]
a draggable interface on your keyboard, but there's different, you can design around,
[00:23:01]
around that pattern.
[00:23:02]
So I think that's my suggestion is don't try to replicate the experience that you have
[00:23:09]
and see if it checks the boxes.
[00:23:11]
Think about it as another design challenge.
[00:23:13]
Gotcha.
[00:23:14]
Kind of like when you do mobile first, you design for mobile, but then you automatically
[00:23:20]
get desktop first, desktop supports.
[00:23:23]
And here you're thinking about accessibility first, right?
[00:23:27]
That's what I'd like to aim for.
[00:23:29]
Although since I think many of us have legacy code to support, you're also thinking accessibility
[00:23:36]
now, I suppose.
[00:23:38]
Accessibility backwards.
[00:23:42]
Accessibility fix.
[00:23:43]
Yeah.
[00:23:44]
What do you think about this idea of ARIA not being the first resort, but being the
[00:23:48]
last resort, if you can't achieve an accessible experience without ARIA?
[00:23:53]
Did we describe what ARIA actually is?
[00:23:56]
No.
[00:23:57]
Can you give a brief introduction as to what ARIA is compared to what else we should use?
[00:24:03]
ARIA attributes are attributes that you add on HTML nodes that communicate to other technologies
[00:24:10]
like screen readers, something about the page that you wouldn't otherwise be able to communicate.
[00:24:16]
So maybe if you had a tabbed interface, there's no way to say, I'm a tab section and a tab
[00:24:23]
panel in HTML.
[00:24:25]
And so you could use ARIA to communicate that additional information that says the name
[00:24:31]
of this tab and this tab is controlling this other section of the page.
[00:24:36]
It's something of an extension to what's available in HTML.
[00:24:41]
Right.
[00:24:42]
Is my understanding correct that there's the document object model, the DOM, which we think
[00:24:47]
about a lot doing web development, and then isn't there the accessibility object model
[00:24:53]
or something like that, which is basically a similar mapping of what's on the screen
[00:25:00]
in a way that's going to be interpreted and used by assistive technologies?
[00:25:06]
And ARIA sort of can annotate the things on your HTML tags in a way that's going to be
[00:25:12]
used by that accessible object model.
[00:25:14]
I don't know the details of how the accessibility or how the ARIA attributes work.
[00:25:19]
I do know that you can see an accessibility tree in a lot of the console development tools
[00:25:25]
that'll mostly say what a heading is called, information like that.
[00:25:29]
There's a lot of really pretty good accessibility tooling that's being added to browsers these
[00:25:34]
days like for color contrast checkers and just there's some neat stuff.
[00:25:38]
As far as what to reach for first, I think 100% of the time if you can do something in
[00:25:44]
regular semantic HTML, that's the way to do it.
[00:25:47]
And I also think often you really don't need the custom widget that it might feel like
[00:25:52]
you need.
[00:25:54]
It's time for my modal rant.
[00:25:56]
Please.
[00:25:57]
Yes.
[00:25:58]
Strongly opposed to modals.
[00:26:01]
So pretty much the first thing that I ever learned about web development was that users
[00:26:06]
don't like alerts and you shouldn't do them, that they're a good way to get feedback, but
[00:26:10]
that users hate them.
[00:26:11]
And I was like, okay, don't have popups that make the rest of the page inaccessible.
[00:26:17]
Got it.
[00:26:18]
And then all of a sudden we're like, do have popups that make them less accessible, harder
[00:26:23]
to use, annoying, have interior scroll.
[00:26:27]
That's a mistake.
[00:26:29]
It's wild to me.
[00:26:30]
And then on top of that, I think often you're trying to do something that you could do without
[00:26:35]
the modal.
[00:26:36]
Like suppose you wanted to delete a post on a blog.
[00:26:41]
Maybe you hit delete and then these days you'd probably expect a confirm modal to pop up
[00:26:46]
because you're doing something dangerous.
[00:26:48]
If you go to your console and write confirm and ask a question, you can get that behavior
[00:26:53]
like via the alert style.
[00:26:56]
Perhaps that is better than a modal since it's already built in and then you don't have
[00:26:59]
to build it and you don't have to worry about focus or the backdrop scrolling underneath
[00:27:04]
the modal, any of those annoyances.
[00:27:07]
But if you really suddenly realize that it's annoying to have the page become inaccessible
[00:27:12]
with a confirmation popup, you could try a different design approach.
[00:27:17]
After you hit delete, have an undo button that appears on the page.
[00:27:21]
All of a sudden you haven't interrupted the user experience.
[00:27:24]
They can still realize they made a mistake and undo their mistake, but you haven't interrupted
[00:27:29]
them, you haven't caused this huge hiccup.
[00:27:31]
No bumps in the experience.
[00:27:32]
But how do you capture their email address when they're like halfway through scrolling
[00:27:37]
in your article?
[00:27:38]
Oh.
[00:27:39]
And how do you make sure that they accept the cookies?
[00:27:44]
Two very important questions that I will leave to other minds to figure out.
[00:27:49]
Yeah, that's interesting.
[00:27:51]
That makes me think of this.
[00:27:52]
I don't know, I find myself doing this in Elm often like that Elm makes me rethink complexity
[00:28:00]
because it makes me look it in the eyes and say, yes, I want this complexity.
[00:28:04]
Whereas because all of your state and state changes and everything have to be explicit.
[00:28:10]
So sometimes it makes me reevaluate my designs of a certain UI flow or something and find
[00:28:16]
a simpler way to express something.
[00:28:18]
So it kind of makes me think of that, you know, like if you can rethink an experience
[00:28:23]
and create something that's as good of an experience in a simpler way, why not do that?
[00:28:28]
It is really hard doing the like, so these things that you're talking about where you're
[00:28:34]
using ARIA to make highly interactive widgets accessible, like it's extremely difficult.
[00:28:42]
Would you say that's true?
[00:28:43]
I don't have experience with it, but from what I have heard, it seems to be quite difficult
[00:28:48]
to get that right.
[00:28:50]
Modals are definitely hard.
[00:28:52]
I think it depends a little bit on what custom thing you're doing, but in general, it's much
[00:28:57]
harder to get right than it is to just use HTML.
[00:29:02]
So what are some like common things that require extra care to make sure they're accessible?
[00:29:09]
Like you know, maybe we can talk about them through the lens of your accessible HTML package.
[00:29:17]
Can you walk us through some examples?
[00:29:19]
Like one of the things that you're talking about in your accessible HTML package is like
[00:29:24]
radio buttons, for example.
[00:29:26]
What would an accessible radio button look like?
[00:29:29]
Right, right.
[00:29:30]
So I guess first off, the accessible HTML package has a lot of stuff in it.
[00:29:36]
One of the key things that it does is wrap the existing Elm HTML library and then prevent
[00:29:43]
event listeners on elements where you probably don't want any actual events.
[00:29:48]
You would want to prevent unclicks on divs, would you?
[00:29:51]
Yeah, so no more clicks on divs.
[00:29:54]
Although, you know, if you're doing your own custom modal, you probably do want the backdrop
[00:29:59]
to be a div and you probably do want it to be clickable.
[00:30:02]
And then you want the escape button to close the modal.
[00:30:06]
So the trick you use for that is like attribute never, right?
[00:30:10]
Or HTML never in some cases?
[00:30:12]
Yeah, so none of those none of those HTML helpers that shouldn't have event listeners
[00:30:18]
can have event listeners added to them, thanks to the type system.
[00:30:22]
Yeah, that's very cool.
[00:30:23]
And then the other parts of the library include helpers for ARIA attributes.
[00:30:29]
And I've tried as much as possible to be thorough in the documentation, because I know that
[00:30:34]
I won't remember it.
[00:30:35]
So I tried to write documentation that would be helpful for me to understand as well.
[00:30:41]
Right, so then with radio buttons, you're going to want when you have a radio button
[00:30:47]
for the radio button to have a label so you know what it is.
[00:30:53]
And then there's a lot of keyboard behavior that you might not realize exists with radio
[00:30:57]
buttons.
[00:30:58]
So radio buttons have the same name, so they're kind of grouped, the right arrow should loop
[00:31:04]
you through loop you through those radio button options, the left arrow should loop you through
[00:31:09]
those radio button options.
[00:31:11]
And that's the kind of behavior that can be really hard to replicate if you're trying
[00:31:13]
to make a custom version of a radio button.
[00:31:17]
So you'll notice if you actually like try to interact with an HTML radio button, that
[00:31:22]
there's a number of modes of interaction, you've got you're clicking on your label,
[00:31:27]
you've got you're clicking on the little do hickey part, the click the circle, the circle,
[00:31:32]
you can click on the circle a bit.
[00:31:35]
And then there's like the spacebar, there's right and left arrows.
[00:31:38]
And you would if you were building a custom radio button, you would have to replicate
[00:31:42]
all of that behavior.
[00:31:43]
So what you probably actually want to do if you didn't want the default circle is to put
[00:31:49]
an SVG over the circle.
[00:31:51]
So you're hiding what the circle looks like, but you're still getting all of the all of
[00:31:56]
the behavior.
[00:31:57]
Right.
[00:31:58]
I see people using this kind of technique with like, like list items and you know, unordered
[00:32:04]
lists a lot where like, if you wanted check marks next to it, then instead of just having,
[00:32:10]
I don't know, a bunch of divs with a checkmark element in front of it, it semantically is
[00:32:16]
going to be better if you have an unordered list with list items, and then you have whatever
[00:32:21]
the like list display none or whatever that is to hide the default bullet points.
[00:32:28]
And then you can insert your own with CSS with you know, content before that type of
[00:32:32]
thing.
[00:32:33]
I think that there's a can't you use an SVG there directly?
[00:32:37]
Oh, maybe.
[00:32:38]
Yeah.
[00:32:39]
list item, something list item style, probably list style image seems like a thing.
[00:32:46]
Unfortunately, you can't as far as I know, do that with the the checkbox little image
[00:32:52]
or the radio button circle.
[00:32:55]
I don't I don't know what to call those, which does mean that it's trickier to get like a
[00:33:00]
custom feel a custom look and feel with the radio button.
[00:33:05]
One thing to consider when trying to make a custom feel and custom experience is that
[00:33:09]
part of accessibility includes folks with cognitive disabilities.
[00:33:14]
When you make your site more custom, and less like the patterns that exist on the desktop
[00:33:20]
on other sites on the less like the browser that they're choosing to use, you're increasing
[00:33:27]
the difficulty of learning how your site works, you're introducing new patterns, introducing
[00:33:31]
new ideas, introducing new icons, and there's a cost to that.
[00:33:36]
I think if you picture the person, you know, who's the least comfortable on a on a site,
[00:33:41]
the person when you say button, they say, huh?
[00:33:45]
Yep, right.
[00:33:47]
It's hard.
[00:33:48]
It's hard for folks.
[00:33:49]
Yeah, it makes me think of, you know, just the principle of progressive enhancement,
[00:33:54]
which seems to be just solid, solid advice.
[00:33:58]
So, you know, a solid principle to keep in mind when doing web development is, you know,
[00:34:04]
start with start with something that more or less would if you took out your CSS, and
[00:34:09]
just had the default built in browser styles, just your HTML, ideally, it should look somewhat
[00:34:15]
usable and represent what the hierarchy is and that sort of thing.
[00:34:19]
And then you enhance that with CSS rather than making it usable with CSS, you're enhancing
[00:34:26]
a usable plain thing into an enriched, more beautiful thing that's still functional.
[00:34:33]
And that, that principle is going to make you keep you honest about making it functional
[00:34:38]
at the core.
[00:34:39]
Yeah, I love that.
[00:34:40]
And actually, I've heard that advice for if voiceovers an intimidating thing to try as
[00:34:45]
a first step, try just removing your styles.
[00:34:48]
Okay, yeah.
[00:34:49]
See what, what does your site look like?
[00:34:51]
Yeah, that's a nice, that's a nice idea.
[00:34:53]
It also occurred to me that like, maybe something a habit we could build as developers to help
[00:34:59]
with this kind of thing is to just become more keyboard centric, for example, right?
[00:35:04]
Like, if we, if we get used to using the tab key to navigate, and we would be frustrated
[00:35:11]
if we didn't see like a skip to main link, and, and that might raise the bar for our
[00:35:16]
accessibility in our own development.
[00:35:19]
I could see that.
[00:35:20]
Although then we'd have to keep in mind that we weren't overlooking the mouse experience.
[00:35:24]
That's important to fair enough.
[00:35:26]
I'm sure there's someone else on the team who will think about that one.
[00:35:30]
Yeah, interesting.
[00:35:32]
So do you have any thoughts on forms with regard to accessibility?
[00:35:38]
Because that's, I mean, maybe that's a whole can of worms, but
[00:35:41]
what about forms?
[00:35:42]
Well, for one thing, with the concept of progressive enhancement, like sometimes with, you know,
[00:35:48]
sort of JavaScript framework based, including Elm web development, it's tempting to just
[00:35:53]
build an entirely custom experience for submitting data, but not using a form to do so.
[00:36:00]
Because we have the power of JavaScript.
[00:36:02]
So we don't need to even wrap things in a form.
[00:36:05]
You know, we don't want to use this sort of old fashioned serialization format to send
[00:36:10]
things to the server.
[00:36:12]
And so like, let's just use JavaScript and hidden API using JavaScript.
[00:36:16]
So like, is that is that an accessibility red flag?
[00:36:20]
Like what would, could that lead to accessibility issues?
[00:36:23]
I'm not sure.
[00:36:24]
I haven't looked into forms at any depth.
[00:36:28]
Uh huh.
[00:36:29]
Yeah.
[00:36:30]
Interesting.
[00:36:31]
Well, I'll have to Google that one a little bit.
[00:36:32]
It's just something I see.
[00:36:33]
I see a lot of frameworks more and more sort of like react remix and Svelte kit now are
[00:36:40]
trying to build in some helpers that make it easier to work with sort of progressively
[00:36:46]
enhancing forms so that if you, you know, I mean, some of them are trying to do it so
[00:36:52]
that if you turn off JavaScript, you can still do that.
[00:36:54]
It's difficult to get an experience in Elm where you can turn off JavaScript and have
[00:36:59]
a usable experience.
[00:37:01]
But it still seems like having forms as something you progressively enhance, um, could have
[00:37:06]
some accessibility benefits.
[00:37:07]
So I'll have to, I'll have to research that a bit.
[00:37:09]
Yeah.
[00:37:10]
I was wondering the same thing about forms because I never use the form tag.
[00:37:15]
That said, I never use any HTML tag except div and span.
[00:37:19]
Hmm.
[00:37:20]
Well, sometimes I notice when I'm like, if you wrap something in a form in Elm, like
[00:37:27]
let's say if you don't wrap something in a form and you just have some inputs, what if
[00:37:30]
somebody edits some forms?
[00:37:33]
Maybe you go back to a previous input field and then you hit enter, right?
[00:37:38]
It should submit the form.
[00:37:39]
And that's, you know, like you were talking about Tessa, that experience that somebody
[00:37:43]
might be familiar with a certain experience, whether, whether it's because they're like
[00:37:47]
a power user who, um, you know, is visually impaired and therefore is very comfortable
[00:37:53]
at the keyboard or somebody who's like new to using browsers and they're just trying
[00:37:59]
to use it and they're used to hitting enter into them, enter means go and they're, they're
[00:38:05]
confused.
[00:38:06]
Whatever it is, that's like the expected experience.
[00:38:09]
And that comes built in with on submit.
[00:38:12]
If you hit enter, there's an on submit event, right?
[00:38:15]
So you have to build in all these experiences.
[00:38:18]
If you don't use a form, you have to ensure that whatever, whatever things happen when
[00:38:24]
you, when you hit enter or, you know, perhaps, I don't know, perhaps on a mobile device,
[00:38:30]
there are certain, you know, maybe the, the keyboard input is going to say a particular
[00:38:34]
thing and you have to ensure all those things happen if you don't use those built in things.
[00:38:39]
And you know, if you also leverage certain input types on the keyboard, you're going
[00:38:44]
to get those benefits out of the box.
[00:38:46]
So again, it's like if, if the browser platform, if the web platform provides something generally,
[00:38:52]
you can't go wrong using that thing as a starting point.
[00:38:55]
I definitely agree with that.
[00:38:56]
I really feel like HTML is pretty good.
[00:38:59]
Yeah.
[00:39:00]
They did some good work over there.
[00:39:01]
Yeah.
[00:39:02]
So I was wondering, like, cause I've seen your talks about accessible HTML and I think
[00:39:07]
they're great and the library looks great, but I never hear people use it actually.
[00:39:13]
I never hear people saying that they use it.
[00:39:15]
Do you use it in no reading?
[00:39:16]
Do you know if other people are using it?
[00:39:18]
We do use it at no reading.
[00:39:20]
I wouldn't say that we use it exclusively.
[00:39:23]
I think part of that though is that we do still have some clickable spans and clickable
[00:39:29]
divs and such.
[00:39:30]
So we have the, we have the problem that the library is trying to prevent in some of the
[00:39:34]
older code.
[00:39:35]
So we don't use it everywhere.
[00:39:38]
I think it's really helpful for ARIA attributes for adding, adding those important attributes
[00:39:46]
because otherwise you have to write them out as strings and that's kind of a pain.
[00:39:51]
So just as a convenience, I think it's really helpful for that.
[00:39:54]
Your code is a little bit less littered with strings.
[00:39:57]
Whether you want the event listener prevention or not, I think that that's a taste consideration
[00:40:04]
to some degree.
[00:40:05]
And then also, I suppose I should be more specific at no red ink.
[00:40:08]
We use accessible HTML with CSS, which will enable you to use Richard Feldman's Elm CSS
[00:40:15]
library as well because Elm CSS also wraps HTML.
[00:40:18]
So we're doing some, you know, you wrap, you wrap, you wrap.
[00:40:22]
Yes.
[00:40:23]
Yep.
[00:40:24]
It's a challenge in Elm.
[00:40:25]
You get all these drop in replacement libraries that it's just like, it's just like this one,
[00:40:30]
except there's this one thing changed.
[00:40:32]
You know, like MiniBill has this wrapper around Elm UI that's like Elm UI with context and
[00:40:39]
you can't get context, which is like helpful.
[00:40:41]
But then what if there's another wrapper that's trying to achieve a similar thing and you
[00:40:46]
can't compose those wrappers together.
[00:40:49]
So it's a challenge.
[00:40:50]
But I believe accessible HTML and accessible HTML with CSS both use like the underlying
[00:40:56]
types.
[00:40:57]
So they're kind of interoperable.
[00:41:00]
Is that correct?
[00:41:01]
Like the type that you're building with accessible HTML is just HTML.
[00:41:06]
It's not its own HTML type.
[00:41:08]
Right.
[00:41:09]
It's not its own HTML type.
[00:41:10]
So if you wanted to, like, for example, if you had like a highly custom interactive widget
[00:41:16]
that you needed a lot of ARIA attributes for, then you could, you know, you could build
[00:41:21]
that using the accessible HTML package.
[00:41:25]
And then it would just give you something of type HTML, the regular plain old Elm HTML
[00:41:31]
type.
[00:41:32]
And then you could just include that in a regular Elm HTML page.
[00:41:36]
Right.
[00:41:37]
Right.
[00:41:38]
So that's sort of somewhat how you use it at KnowRedInk is to drop in or you try to
[00:41:44]
use it when you can.
[00:41:45]
And if you can't, you can always sort of use them interchangeably.
[00:41:48]
Right.
[00:41:49]
Yeah.
[00:41:50]
That's helpful to know, actually, because I have to admit, I also like I think the that
[00:41:54]
composability issue is challenging because like I use like I've been using Elm tail end
[00:41:59]
modules a lot, for example, which uses Elm CSS.
[00:42:03]
But actually, you could interoperate with Elm CSS and, you know, there's nothing preventing
[00:42:08]
you from using those two things together.
[00:42:10]
I think you do want to, you probably want to pick between accessible HTML and accessible
[00:42:14]
HTML with CSS.
[00:42:15]
Definitely.
[00:42:16]
Right.
[00:42:17]
So you're not doing like the too unstyled from unstyled move too much.
[00:42:22]
But as long as you're decided on whether you want Elm CSS or not Elm CSS, you should be
[00:42:27]
able to conveniently use accessible HTML or accessible HTML with CSS.
[00:42:32]
And you can use the attributes without using the HTML node helpers if you're not interested
[00:42:38]
in the node helpers.
[00:42:40]
That's awesome.
[00:42:41]
Yeah, that's a very elegant design.
[00:42:42]
Okay, I'm gonna have to I'm gonna have to try that out.
[00:42:44]
Because I have to admit, I've been a little intimidated by the this, this composable Elm
[00:42:49]
library challenge.
[00:42:50]
But I think you've sort of come up with a pretty elegant solution to that.
[00:42:54]
That's nice.
[00:42:55]
Although having the two libraries that are basically identical to each other has made
[00:42:59]
me want to update them less, like, Oh, I have to do everything twice.
[00:43:03]
Yeah.
[00:43:04]
Yes, definitely.
[00:43:05]
Do you think it's a good idea to just replace Elm HTML, or sorry, to replace HTML imports
[00:43:13]
by accessibility in a lot of pages to see where their accessibility issues?
[00:43:19]
Yes.
[00:43:20]
I mean, I don't think it'll get you 100% of the way at all.
[00:43:23]
I think it's I think you could definitely can do a drop in replace for HTML with accessibility,
[00:43:30]
the accessibility library.
[00:43:32]
I think you should also augment that with adding the axe dev tools, ci pieces and, and
[00:43:41]
do all of the all of the other work that goes along with it.
[00:43:44]
I don't I don't think that using accessible HTML is sufficient.
[00:43:47]
It's an option.
[00:43:50]
It's a tool in your toolkit.
[00:43:51]
Yeah, right.
[00:43:52]
Right.
[00:43:53]
Just like using Elm HTML doesn't prevent you from writing invalid HTML, but it hopefully
[00:43:59]
help helps you from a couple of pitfalls.
[00:44:01]
Yes, it's one one step on the on that road, which is which is nice.
[00:44:05]
I mean, Elm is definitely part of that, that are that robust, robust are.
[00:44:11]
Yes.
[00:44:12]
Yeah, it's like, you're in often often says, like, if you can, you know, it sort of a I
[00:44:19]
don't know, Maslow's hierarchy of, of type safety or, you know, static guarantees, like
[00:44:25]
if you can prevent something through types, then that's your number one go to if you can
[00:44:31]
prevent something through API design through hiding certain things, but the types themselves
[00:44:37]
could represent impossible states, but the API prevents certain impossible or undesirable
[00:44:43]
states.
[00:44:44]
That's, you know, your second thing you reach for.
[00:44:47]
And then your third thing you reach for might be something like code generation.
[00:44:50]
And the fourth thing you reach for might be an Elm review rule.
[00:44:53]
But like, if you can do it any of the other closer to the metal ways, like having the
[00:44:57]
type make it unrepresentable, you should reach for that.
[00:45:00]
And that's essentially what accessible HTML is.
[00:45:03]
It's it's, well, it's it's more using the API design to prevent those impossible states
[00:45:07]
because the underlying types are the same.
[00:45:08]
But that's closer to the metal higher up in in your own hierarchy of static checks.
[00:45:13]
Yeah, it's the one that gives you the best feedback, right?
[00:45:17]
And the best guarantees as well.
[00:45:19]
Yep.
[00:45:20]
Because there's no escape hatches in the compiler.
[00:45:22]
So because I know there are escape hatches in accessible HTML, there are escape hatches
[00:45:27]
in Elm review.
[00:45:28]
So go for types when you can.
[00:45:31]
Yeah.
[00:45:32]
So when when you use Elm HTML, the core one over accessible HTML,
[00:45:36]
I would almost always use it if I was just making a little le demonstration of something
[00:45:41]
because then I don't have to add another package.
[00:45:43]
I would also use it if I knew that the thing I was doing was fine.
[00:45:48]
And then I would probably leave a comment explaining why I think it's fine.
[00:45:52]
And maybe I'm wrong, but at least that that note is there.
[00:45:55]
So in the in the modal example that we were talking about, often when a modal is open,
[00:46:01]
you have a trans a translucent backdrop to the modal that's making the rest of the screen
[00:46:07]
harder to see.
[00:46:08]
And a common pattern is that a mouse user is able to click on that backdrop to dismiss
[00:46:14]
the modal.
[00:46:15]
I think this is a nicer user experience since it's easier to get out of a painful, interruptive
[00:46:19]
experience that nobody wanted ever.
[00:46:24]
And I think in this case, you could make the backdrop a button or you could do something
[00:46:29]
with the backdrop to make it an element that expects focus.
[00:46:32]
But when I think about what the equivalent user experience is for a primary keyboard
[00:46:38]
user, what I want to do as a keyboard user to exit the modal is hit escape.
[00:46:42]
I don't want to tab to the backdrop and then click the backdrop with by hitting the spacebar.
[00:46:50]
That's a weird experience.
[00:46:51]
Yeah, potentially it also triggers a button or a link.
[00:46:55]
So I mean, it's just it's definitely odd.
[00:46:59]
Whatever else it does, it's not intuitive.
[00:47:03]
So in that case, where I know that I want an event listener on the backdrop, the backdrop
[00:47:08]
is probably going to be something that shouldn't receive focus like a div.
[00:47:11]
I don't want to adhere to the idea that you should never, never, never have a clickable
[00:47:16]
div.
[00:47:17]
I want to think, can every user that wants to access that wants to exit this terrible
[00:47:22]
modal get out?
[00:47:24]
Because I trapped users in the worst UI element that exists.
[00:47:29]
So in that case, I would use Elm HTML and Elm HTML node for the backdrop and not worry
[00:47:36]
about about adding that event listener.
[00:47:39]
I think I would also be willing to use Elm HTML directly if I felt confident that I knew
[00:47:45]
what elements should have event listeners and what elements shouldn't.
[00:47:49]
If I had 100% certainty that I was right about where focus was available by default or where
[00:47:55]
tabability is available by default and was really confident that I was doing the right
[00:47:58]
thing, maybe I wouldn't be as inclined to use accessible HTML.
[00:48:03]
Well, not as inclined to use the HTML node constructors and accessible HTML.
[00:48:08]
I think I would still use the ARIA helpers.
[00:48:12]
So you've done a lot of work at No Read Ink, Tessa, trying to improve accessibility.
[00:48:17]
And I know you've really tried to make an effort to keep things really accessible in
[00:48:24]
the No Read Ink codebase.
[00:48:25]
So what are some of the lessons you've learned and some of the journeys you've gone through
[00:48:30]
in that process?
[00:48:31]
Yeah.
[00:48:32]
So I think one thing that's been really awesome at No Read Ink is that I've gotten a lot of
[00:48:35]
support in exploring whatever has interested me, whatever interest I've had.
[00:48:41]
And I've been encouraged to follow my interests and grow and bring learnings back to the team.
[00:48:47]
So luckily that has helped me to have room to learn more about accessibility.
[00:48:52]
The most successful thing that I think we've done so far is started a, well, I suppose
[00:48:57]
it started as a learning group.
[00:48:58]
We call it Fab Friday and it's FAB in all caps.
[00:49:02]
And I have no idea what it stands for.
[00:49:04]
We didn't write it down.
[00:49:05]
Fabulous?
[00:49:06]
But why is it in all caps though?
[00:49:09]
I don't know.
[00:49:10]
Because it's very fabulous?
[00:49:11]
It definitely is fabulous.
[00:49:12]
No question.
[00:49:13]
All right.
[00:49:14]
Yeah, but we started a learning group meeting on Fridays that then expanded into auditing
[00:49:23]
and improving reusable widgets.
[00:49:26]
We have actually a package of reusable widgets and we went through those and tested them
[00:49:32]
and tried to improve them.
[00:49:34]
And actually using Netlify for that package was really helpful because it made the feedback
[00:49:39]
loop really fast and we could, a developer could make a PR with an idea with like a,
[00:49:45]
is this, does this work?
[00:49:47]
And then the awesome person on the QA team, Christine Horn, who's part of Fab Friday could
[00:49:52]
help us go through it on Netlify and get that feedback without having to publish it or without
[00:49:59]
having to commit to it.
[00:50:00]
Yeah, that's very cool.
[00:50:02]
And then from there we started working on some of the more legacy code on our site,
[00:50:08]
what we call the quiz engine.
[00:50:10]
So that's the part of the site that many, many, many students are using.
[00:50:15]
And it's kind of been a gradual progression from thinking about ourselves as a learning
[00:50:20]
group to thinking about ourselves as able to improve widgets that are used across the
[00:50:24]
site.
[00:50:25]
So having a big impact, but making small changes to being willing to work directly on the intimidating
[00:50:31]
parts that get a ton of use and that have been kind of an obstacle when we've thought
[00:50:35]
about accessibility, because it's been like, well, it's hard because this seems impossible.
[00:50:39]
So I guess we can't, I guess we can't do it because there's components that have drag
[00:50:44]
and drop and very fancy formatting.
[00:50:47]
They're very complicated interfaces, but starting small and working together and being a group
[00:50:53]
really helped us to build our confidence to where we were able to take on the hardest
[00:50:58]
challenge.
[00:50:59]
Yeah.
[00:51:00]
So first recommendation is if you can work with Christine Horn, then do go ahead and
[00:51:05]
do it.
[00:51:06]
But hopefully that will only be available to you if you come work with me.
[00:51:12]
Is this a time where we say that nobody is hiring?
[00:51:15]
Oh yes, please take it away.
[00:51:20]
The other thing that we've tried to do as part of Fab Friday is make cues of tackleable
[00:51:26]
work, the smaller changes.
[00:51:30]
Loading fruit.
[00:51:32]
And things that are simple and easy to describe, like you mentioned prefers reduced motion
[00:51:38]
earlier.
[00:51:40]
Making those changes has a huge impact for users who are going to have a physical reaction
[00:51:46]
to animation.
[00:51:48]
You can just help someone to not be nauseous.
[00:51:50]
You can just stop causing someone's nausea.
[00:51:54]
If you know where the animations are.
[00:51:56]
So how do you hear about those issues?
[00:51:58]
How do you detect them?
[00:51:59]
Is it mostly through user complaints, user issues?
[00:52:03]
We definitely get user complaints when things are painful for users.
[00:52:09]
I think some folks on the team are also very attuned to news articles and like new releases
[00:52:15]
and changes.
[00:52:17]
And people will mention those in our topic accessibility Slack channel.
[00:52:21]
I think a lot of folks are very interested in the topic and will paste links and articles
[00:52:27]
in that channel.
[00:52:28]
Our curriculum team in particular is often very interested in accessibility because they're
[00:52:34]
always thinking about accessibility from more of a content perspective.
[00:52:37]
If you picture a school, of course, teachers need to be keeping accessibility in mind and
[00:52:43]
need to be thinking about how to make their classrooms work for the students who are in
[00:52:48]
their classroom.
[00:52:49]
Yeah, so I think it's mostly people paying attention and then bringing ideas back to
[00:52:54]
the group.
[00:52:55]
Something that you said, I think at the reactive talk that you made is that if your accessibility
[00:53:02]
is terrible on your website, a lot of people won't stay on your website and they will just
[00:53:07]
go to another product or something like that.
[00:53:09]
So you won't hear those complaints.
[00:53:11]
So if your accessibility is very bad, then you as a developer have to step up to improve
[00:53:16]
those issues.
[00:53:17]
I mean, in the case of KnowRedInk, it's the teachers or the schools that subscribe or
[00:53:22]
adopt KnowRedInk.
[00:53:24]
So you're kind of forced to get all the accessibility issues from the students.
[00:53:28]
But I think for other people, other products, that will not be the case.
[00:53:31]
They will not have that good feedback.
[00:53:34]
Yeah.
[00:53:35]
And actually, one of the reasons that I feel so strongly about it being important to make
[00:53:39]
things accessible is that I feel like our student users don't have as much choice as
[00:53:44]
most users do.
[00:53:46]
And that means to me that it's really, really important that we do right by them.
[00:53:51]
When people can't choose not to use your product, you have a higher obligation to them.
[00:53:55]
Yeah.
[00:53:56]
Totally.
[00:53:57]
Man, that puts a lot of pressure.
[00:54:00]
Well, there's always pressure and we can only do our best.
[00:54:04]
We can only do what we can do.
[00:54:06]
Yeah, it seems like the accessibility champion is a common way that companies get more accessibility
[00:54:13]
these days.
[00:54:14]
But I think more and more, hopefully it'll be built in and we'll develop these skills
[00:54:20]
better as developers who aren't, maybe it's not our specialty, but we'll be somewhat versed
[00:54:26]
in it.
[00:54:27]
We're somewhat versed in doing accessible or responsive pages.
[00:54:30]
I'm optimistic that as an industry, we'll be able to learn more and have broader knowledge.
[00:54:36]
Yeah.
[00:54:37]
And maybe have better built ins and things that provide an accessible out of the box
[00:54:44]
experience that we can leverage by making use of the platform.
[00:54:48]
So I'm curious Tessa, are there any, is there a little toolkit of biggest bang for your
[00:54:55]
buck things that you find yourself reaching for and getting the most use out of for somebody
[00:55:03]
like maybe myself and Jeroen who are not as knowledgeable about accessible experiences?
[00:55:10]
What are some of your go tos that give you the most benefit?
[00:55:12]
I suppose, do you mean like a pre made widget or more a blog post or a learning resource?
[00:55:18]
Yeah.
[00:55:19]
I mean, any of those, a place to start a thing to be aware of, principle, whatever's helped
[00:55:25]
you the most.
[00:55:26]
I think the principle that's helped the most or the approach that's helped the most is
[00:55:33]
working with other people so that you're not staring at a spec by yourself and starting
[00:55:39]
in a concrete place.
[00:55:41]
I think when we all learned HTML, we probably didn't start by reading the entire HTML spec.
[00:55:48]
I expect that there's plenty of HTML tags that folks have never heard of and that's
[00:55:53]
great.
[00:55:54]
I mean, no worries.
[00:55:55]
I think as long as there's a moment of, is there a way to do this task in HTML?
[00:56:03]
Is there a way to do this accessibly?
[00:56:05]
Searching on the internet for what other people have done, reading blog posts, looking at
[00:56:10]
the resources that are available for the particular task that you're trying to do, that can help
[00:56:14]
you to success in a way that trying to learn everything upfront and then remember it until
[00:56:20]
you need it won't.
[00:56:21]
Right.
[00:56:22]
Right.
[00:56:23]
And having that motivation too, like if you can somehow see the result of something being
[00:56:29]
accessible or not, then it's just really hard to be motivated if it's an abstract concept
[00:56:35]
that you don't know what it actually, what the problem looks like.
[00:56:38]
If you can look at the problem, then it motivates you to fix it more.
[00:56:42]
Like if you're trying to use voiceover or trying to use JAWS or...
[00:56:47]
It definitely gave me a sense of motivation when I was looking at some of my sites and
[00:56:53]
realizing that the page navigations aren't announced.
[00:56:57]
When you change the page, you navigate in a link using voiceover and it's very anticlimactic.
[00:57:03]
Nothing happens.
[00:57:04]
So it's like, wow, that's pretty important and I'm going to need to...
[00:57:09]
I mean, fortunately, a lot of companies have written extensively about, for example, like
[00:57:15]
making Gatsby.js accessible in their page navigations or Reach Router and they've shared
[00:57:22]
the results of their research.
[00:57:25]
So I could build that into Elm pages and make it accessible out of the box.
[00:57:31]
Maybe Ryan can do that in Elm SPA as well.
[00:57:35]
And then we can...
[00:57:36]
I mean, that's also a game changer is if we can build these things into our tools, like
[00:57:41]
the accessible HTML package and who knows, maybe there's some room for some Elm review
[00:57:46]
rules to help out with the things that we can't check through API design.
[00:57:51]
Totally.
[00:57:52]
Do you think it would be a good idea for the application starters or for Elm pages or Elm
[00:57:58]
SPA to start with accessible HTML rather than Elm HTML?
[00:58:02]
Would that be cool?
[00:58:03]
I feel hesitant pushing...
[00:58:06]
That feels like pushing my work on people who might not want it.
[00:58:11]
There are escape hatches and it's just Elm HTML anyway.
[00:58:14]
So...
[00:58:15]
That's true.
[00:58:16]
There are some slight changes.
[00:58:18]
It's not a direct copy in all cases.
[00:58:21]
Like the image helper tries to encourage you to use alt text or to use a decorative image
[00:58:28]
which has alt text to empty string.
[00:58:31]
That's kind of the point.
[00:58:33]
That is kind of the point, but it might make documentation harder.
[00:58:38]
You would want to say very explicitly that it wasn't using HTML.
[00:58:42]
I guess I worry about beginners to Elm who are going through the guide and see import
[00:58:47]
HTML and then it doesn't work.
[00:58:49]
And then they're unhappy.
[00:58:52]
At the very least, I think even more so if you're building a site, then accessibility
[00:58:59]
is important.
[00:59:00]
If you're building a framework, like you were saying earlier, Tessa, that if a user is not
[00:59:06]
able to choose something else, then you have a responsibility to make that experience accessible
[00:59:12]
because they don't have a choice.
[00:59:13]
If you're building a framework, then the things that are built into the framework really do
[00:59:18]
have a responsibility to be accessible in those core features too.
[00:59:22]
So I'm going to take a look at making my single page page navigations accessible in Elm pages
[00:59:30]
because that's like, I mean, Elm pages users don't have an option there.
[00:59:34]
And so I think those things should really be built in the framework.
[00:59:38]
And frameworks have a unique opportunity to put a lot of thought into something so that
[00:59:42]
other people get it for free, which is great.
[00:59:45]
So that's the ideal.
[00:59:46]
Well, that sounds awesome to me.
[00:59:49]
Yeah.
[00:59:50]
Yeah.
[00:59:51]
But using the, you know, using voiceover on my computer, which I just hit command F5,
[00:59:56]
I finally, finally went through some of my sites and tried to like consume them.
[01:00:02]
I didn't close my eyes or make the pages not visible or anything, but just going through
[01:00:09]
that experience was really good.
[01:00:11]
I'm going to be doing that more.
[01:00:13]
And it feels like less intimidating now that I just tried it to reach for that as a testing
[01:00:17]
device, just like I would pull up a mobile simulator to make sure that things aren't
[01:00:23]
overflowing in a weird way and look reasonable on mobile.
[01:00:26]
And there is a built in voiceover tutorial that you can go through, which might be a
[01:00:32]
good place to start.
[01:00:33]
That's cool.
[01:00:34]
I don't know how to get started on JAWS or NVDA, but if you're on Windows, those are
[01:00:39]
the things to try.
[01:00:40]
I saw a video of someone recently using an iPhone with the voiceover and she was like
[01:00:46]
hovering over a region on the screen and it was reading it.
[01:00:49]
And she was using Braille to type and was so like way faster than I am to type.
[01:00:54]
But it was really cool to just see how.
[01:00:57]
And I guess that's one way to consume voiceover is to sort of like hover over a region and
[01:01:02]
have it read it for you.
[01:01:04]
But it's just starting with that awareness is really valuable.
[01:01:10]
It's amazing some of the physical tools that are out there, like the Braille displays.
[01:01:15]
And I learned about a cording keyboard recently, which I suppose operates somewhat similarly
[01:01:21]
to a stenographer keyboard, except that it's more aimed at one hand.
[01:01:25]
So you're like cording on one hand.
[01:01:30]
That's awesome.
[01:01:31]
Right.
[01:01:32]
I wouldn't know where to get started with that either.
[01:01:34]
It seems like really neat, really pretty neat.
[01:01:37]
That's incredible.
[01:01:38]
And also the voice, the speech to text tooling is, I think, much improved these days.
[01:01:45]
There was a really cool talk at Strange Loop 2019.
[01:01:48]
Emily Shea talked about voice driven development.
[01:01:51]
She's a developer with RSI and the whole talk.
[01:01:55]
She was talking about her process as a developer, but then she's also saying like next slide
[01:02:00]
to actually control her computer during the presentation.
[01:02:03]
Oh, cool.
[01:02:04]
Yeah.
[01:02:05]
Yeah.
[01:02:06]
I think people are going to be probably using like voice assistant devices, sometimes just
[01:02:10]
for personal preference that they want to use their voice assistant to navigate a website.
[01:02:17]
And so accessibility is also just being able to access content or sites through more devices.
[01:02:27]
I think it's like that classic example of accessibility making life better for everybody
[01:02:31]
with curb cuts.
[01:02:32]
I don't think I know that one.
[01:02:35]
I don't know what a curb cut is.
[01:02:37]
So you know a sidewalk and then at the corner it usually swooshes down to the level of the
[01:02:43]
pavement so that a wheelchair user can access the sidewalk.
[01:02:48]
But then if you're walking, you don't have to do a big step up all the time.
[01:02:53]
And if you have a stroller or a push cart of groceries, it just makes life nicer for
[01:02:59]
everybody.
[01:03:00]
Yeah.
[01:03:01]
So that's maybe a great note to close on, but before we wrap up, are there any resources
[01:03:08]
that you want to point people to besides what we'll definitely link to Tessa's accessible
[01:03:14]
HTML and accessible HTML with CSS packages and all the links that we referred to in the
[01:03:22]
episode?
[01:03:23]
But are there any other helpful links that you want to point people to?
[01:03:27]
Yes.
[01:03:28]
So I recommend the WCAG web content accessibility guidelines.
[01:03:33]
That will be overwhelming if you try to read all of it, but if you need a reference for
[01:03:37]
a particular thing that you're trying to accomplish, I think webaim.org is also pretty good.
[01:03:44]
There was a good talk at the Juneteenth conference 2020 called Empowerment to the People, What
[01:03:50]
You Need to Know about Black People, Disability and Accessibility by Angela Hooker.
[01:03:54]
And then Axcon happens every year and tons of excellent talks from people with much deeper
[01:04:02]
expertise than me.
[01:04:03]
And you see, you should definitely take a look at some of those.
[01:04:07]
And we mentioned Deque with the, they're the makers of the Ax developer tools.
[01:04:12]
They have a lot of resources on their website and there is a free tier for the dev tools
[01:04:19]
that you can get started with.
[01:04:20]
It's a little hard to find on their site, but it does exist.
[01:04:23]
So you can try it out.
[01:04:24]
Fantastic.
[01:04:25]
Well, thank you so much for coming on the show, Tessa.
[01:04:28]
And how can people follow you or KnowRedInk and find out more?
[01:04:33]
Yeah.
[01:04:34]
So I believe that my Twitter is T underscore Kelly nine.
[01:04:38]
You can expect not to hear from me there, but that's where I am.
[01:04:44]
And then I'm Tesc9 on GitHub, T E S K nine.
[01:04:49]
And then KnowRedInk, we're hiring.
[01:04:52]
The constant message.
[01:04:54]
Beautiful.
[01:04:55]
Come work with me.
[01:04:56]
Is there a hiring page?
[01:04:57]
There's a careers page.
[01:04:58]
There should be a hiring page.
[01:05:00]
Yes.
[01:05:01]
KnowRedInk.com slash jobs.
[01:05:03]
Beautiful.
[01:05:04]
Well, thanks so much for coming on Tessa.
[01:05:06]
Pleasure chatting.
[01:05:07]
Thank you.
[01:05:08]
This is wonderful.
[01:05:09]
Thanks.
[01:05:10]
And Jeroen, I'll talk to you next time.
[01:05:11]
Thanks for having me.