Accessibility in Elm

Accessibility in Elm

Guest Tessa Kelly walks us through some accessibility best practices and how to apply them in Elm.

PublishedJune 21, 2021

Episode#33

Tessa Kelly (GitHub) (Twitter)
The 4 Principles of Accessibility
prefers-reduced-motion media query
Guide to using Mac's built-in VoiceOver screenreader
Ace Accessibility tools
Skip Links
Navigating headings with a screenreader (see keyboard shortcuts for the VoiceOver rotor)
WCAG checklists
VPAT documents
ARIA attributes
The Accessibility Tree
Google's explanation of The Accessibility Tree
An API for the Accessibility Object Model is in draft form
Avoid modals, instead try a different ux
Accessible radio buttons
Tessa's Accessible HTML package tesk9/accessible-html
list-style-image in CSS
Progressive enhancement
Remix's approach to progressively enhancing forms
Package for using Accessibile HTML with elm-css - tesk9/accessible-html-with-css
Jeroen's hierarchy of static checks
Chorded keyboard
Emily Shea's talk Voice Driven Development: Who needs a keyboard anyway?
WCAG accessibility guidelines
webaim.org
Angela Hooker's Juneteenth Conf talk Empowerment to the People! What You Need to Know about Black People, Disability, and Accessibility
AxeCon talks
Deque's education resources site - Deque University
Axe Dev tools Chrome extension
Tessa Kelly (GitHub) (Twitter)
NoRedInk jobs

Transcript

And I think we've got an Elm Radio First today, which is our first ever repeat guest.

We've got Tessa Kelly with us again today.

Thanks for joining us.

Thanks for having me.

I'm excited to be here.

I'm excited to learn from you because I think we've got quite a bit of knowledge that we

can absorb from all of your experience with accessibility today.

So well, as we like to do, Jeroen, maybe we can start with a definition of accessibility.

I suspect it may get a little bit philosophical.

Yeah, I think so.

I tend to think of accessibility as being literally about access, being about making

sure that everybody has access to the information, the services, the employment, the educational

materials that are available on the internet and that are important for people to have

access to, not to define accessibility in terms of itself.

Yeah, no, I like that.

One thing I've been thinking about is, for example, if you are in a country that has

limited bandwidth for networks, if you're in the middle of Mumbai, they might have very

powerful cell towers, but they're being used so heavily that the bandwidth is just not

there if you're on a mobile device.

And if you're on a mobile device with a small screen, that could be a type of accessibility.

And if you have a low powered device.

Yes, I suppose there's a layer when you're talking about accessibility of the device

and the tools that you have that you're interacting with in order to access the information.

And then past that layer, there's the human piece.

There's the physical body.

What is your body able to do to interact with the devices that you have?

I think a lot of folks start thinking about accessibility in terms of vision problems,

in terms of blindness, impaired vision, color blindness, but there's many more things that

go beyond that.

Reduced motion is another one that people are starting to think about more these days.

You mean in terms of avoiding animations that folks don't want to see?

Or do you mean in terms of the person themselves has reduced motion?

Yeah, I was thinking about the preferring fewer animations and the media query for prefers

reduced motion, that sort of thing.

But yeah, there are both.

Yeah, so I guess there's just in a way an acknowledgement that the way you're accessing

a website is not necessarily going to be exactly the same as the way somebody else is accessing

Yeah, I think an acknowledgement and then beyond that, an explicit consideration and

design for the usage patterns that someone who's using that different access pattern

is going to require in order to be successful at using your site.

And not just successful, but happy to use your site.

Delighted perhaps?

I think delighted is the thing to go for, yes.

And this becomes a really interesting area too because then there's that ethos and elm

of hopefully we like delighting people with tools, but also hopefully making delightful

web experiences.

But then there's also this question of how can we leverage these awesome tools that we

have in elm like the type system to help with those things, to help remember to consider

these different types of users with different experiences.

And then separate from elm, I think that thinking in terms of developers, developers often think

in terms of user pain, like this will be a painful experience.

And then they also think in terms of their own pain, like I'm going to get a fancy keyboard

so that I don't develop pain.

And when you're talking about accessibility, I think another piece to consider is that

some of your users might be able to achieve a user flow as you've designed it, but they

might experience literal physical pain as a result of trying to use that flow the way

that you've designed it.

So if someone has RSI and it's an injury in the wrist that makes it hard for some folks

to type or use a mouse and it's quite common.

And I mean, I've only ever heard of developers having it, but I'm sure that many people have

So you might have like literal physical pain, making it harder for you to use the physical

interfaces that are in your home.

Or you might have epilepsy triggered by flashing.

You might have migraines or nausea from screen color changes.

I think even before the delight that Elm can bring or the delight that a type system can

bring or the delight that a user interface can bring, there's a moment of don't hurt

people that I think is pretty important.

Like a Hippocratic oath for programmers.

That's a good consideration.

Yeah, I hadn't considered the physical pain element, but that's important if you can induce

pain with your website.

That's a major bug.

Usually I think about accessibility, about people not being able to do what is intended

to be done, to make possible.

But yeah, I didn't think about pain at all.

I know that some people have problems with, as you said, with the epilepsy.

That's not what I had in mind.

Definitely good to know that.

You link to this set of principles, Tessa, in your accessible HTML docs of the principles

of accessibility.

Do you think that those four principles are a good framework to frame your thinking on

I also think that they're really helpful to communicate with folks outside of engineering.

I think many people have a perception that accessibility is about adding the right ARIA

property, and that it's on the engineers and on the engineering side to make sure that

a site is accessible.

But if you start talking about the principles of making your site perceivable, operable,

understandable and robust, you realize that what you're talking about is users.

You're talking about users being able to do something.

You're talking about user stories, and user stories are clearly something that's coming

from product managers, from designers, from folks who are thinking about experiences.

Is it true that there are some legal implications for accessibility in websites as well?

For example, you're working in the education space at No Red Ink.

I think that if you have educational software and it's not accessible, that can actually

have legal implications.

I've heard of trials where, for example, you could even pull out automated accessibility

testing tools as evidence in a trial to show whether or not you were negligent in providing

an accessible website.

I think the requirements differ country to country, state to state.

And I think in law in general, a law that hasn't had litigation doesn't count.

You need the court system to operate before people will feel obligated to follow the law.

Because we work through precedents in at least the United States court system.

That's my impression.

So you're allowed to kill someone unless there is a jury saying, hey, you shouldn't.

It's habeas corpus.

You're allowed to kill somebody as long as nobody finds the body.

You heard it here first.

Getting macrub here on Elm Radio.

Legal advice from Tessa.

To be clear, you should not take legal advice from me.

You should not kill people.

But there are legal reasons to make sure that your site is accessible.

There's good reasons to keep track of what you've done to make sure that your site is

If you're organized and keeping records and doing regular audits, you're going to be in

a better position if there ever is a trial.

But again, based on what I just said about habeas corpus, probably you shouldn't talk

to an actual lawyer.

That seems fair.

I also think that thinking about trials is a very American centric point of view.

Well it just makes it more concrete that these things have happened maybe infrequently.

Not that that should be the motivation, but it's a concrete thing and it's increasingly

the expectation.

When I was getting into web development around 2012 or so, mobile first and responsive design

was this new thing.

It wasn't the norm.

If you had a 1024 by 768 dimensions that you tested on and that was all it worked on, that

I think that we're getting more to a place where you're expected to have accessibility

We're not quite there yet.

We're not quite where we are with expecting responsive first, mobile first now.

But we're moving in that direction.

It's something that is a necessary skill.

But I am really under skilled there and need to learn more.

But I think we should all skill up there right now.

I think it's definitely part of what goes into building quality software.

If you think about the R in perceivable, operable, understandable, robust.

Robust means having tests and making sure that you're using up to date technology.

I think it is part of this larger conversation about what it means to build a good website.

But it is challenging because it does encompass all of these topics and tools.

It is a topic that feels overwhelming.

When you hear about accessibility, people talk about visual impairments.

You're able to focus through keyboards and to do everything with screen readers.

The more you hear about it, the more you hear about people with certain needs, certain problems.

It just feels like a never ending list.

In that sense, it feels overwhelming.

That said, for everything that you want to start improving, the most important part is

the first step.

I didn't do many steps in this regard.

I hope to learn from you here.

I feel like it's very hard to take this big list of a million possible accessibility things

You look at all these possible ARIA attributes and you're like, am I supposed to use them?

Sometimes I hear people saying, if you're reaching for ARIA, it should be the last resort,

not the first resort because you should be using regions and things like that to make

things accessible without the help of ARIA when possible.

Same with building a mobile first site.

There are so many techniques.

If you just read about the techniques in the abstract, it's very difficult to know if you're

hitting the mark.

If you pull up an iPhone simulator or whatever mobile device simulator or open Chrome with

the little mobile dimensions tool, then you're like, oh, this page doesn't look quite right.

I've been wanting to do this for a long time and I just never did until just before recording,

I opened up VoiceOver, the built in Mac screen reader device, and I went through a few websites.

I was learning some of the hot keys and getting a sense for some of the navigation.

I feel like that's got to be the key to making more accessible experiences because, for example,

I went to a couple of my sites and I tried changing to a new page and I noticed that

it didn't read to let me know that the page had changed.

It wasn't aware of that.

That's something I've heard.

I know that Reach Router in React land and a few of these other routers have had a journey

where they lacked accessibility on single page page navigations and they had to figure

out the best practices and pave the way for that.

I think they've started using these Announce, what is it called?

Oh yeah, ARIA Live Region to create these page change announcers so that you can let

an assistive device know that the page has changed.

For example, if you open up a website that you maintain and try that, you're going to

be able to connect more with that experience and understand, maybe I'm not an expert on

using a screen reader, but I can tell there's a major shortcoming that I should fix there.

I think that's a great step.

Also I think believing that any step is a good step to take.

There's so much that you can do in web development in general, but you don't necessarily expect

yourself to be an expert in all the front end technologies, all of HTML, all of CSS,

all of Elm, all of JavaScript, all of it.

You focus on the problems that you're working on and you break them down into smaller pieces

so that they're manageable and not so scary and you work through them.

I think that the same thing has to apply to accessibility.

You won't make progress if you try to memorize everything in WCAG 2.1.

That's going to be really hard.

It's one step at a time.

As we talk about a lot on this podcast, it's all about feedback.

If you can get good feedback, then you can get good things based on that feedback.

I would imagine the same is true for accessibility.

There's a limit to what you can do with automated tests.

What's been your experience with things like Axe and these other automated accessibility

What do you get from those tools?

I think they're helpful.

I don't think that they're a replacement for opening voiceover yourself, but they're definitely

helpful and having them as part of your testing just baked in is great.

In particular, for something like messing up heading order, so you have an H1 and then

all of a sudden you've done something and they're out of order.

That's a very easy mistake to make if you're changing the styles of your headings and you're

not going to see it just by looking at your screen.

It's really helpful to have tooling in place that's going to tell you, you made a mistake

It's just like what you said about the feedback.

Tooling that tells you where you made the mistake is really helpful.

I find it really helpful to actually...

If there's a rule, there shouldn't be multiple H1s in the page or that sort of thing.

I find it really helpful to remember rules that we're supposed to follow if I understand

what happens as a result of not following that rule.

Why don't we take that example?

Can you tell us what would actually happen if we were using a screen reader?

How would the experience differ if we had problematic header hierarchy?

I think a screen reader is going to try to make the page navigable to you without needing

to go through every item on the page.

Your headings are like in an outline for a document or anything like that, structured

content, like an outline for a document or structured content of any type, you want to

be able to provide to that user places where they can find their point of interest quickly

The screen reader will use those headings to make an outline of your site so that the

user can easily jump to the pieces of the site that they care about so they're not forced

to go through every single item and read through every single item, read all your paragraphs

and paragraphs of brilliantly written content.

But my goodness, so long.

I was playing around with voiceover on some sites and I was trying to learn some of the

shortcuts and I noticed there's a shortcut for next heading, but I think that just goes

to any heading.

It will just skip to any heading.

How would somebody using a screen reader or using voiceover in particular navigate, how

would they skip over H3 headings and go to the next H2?

So we are kind of getting into, I've probably got about five hours of straight voiceover

So if you picture my answers as being delivered to you by someone who has used a computer

for five hours, not very good.

I think that the router, there's a view that you can access that gives you more of an outline,

but I don't remember what the shortcut is for that.

Now that makes sense.

So somebody who's very well versed in using assistive technology would be comfortable

just flipping between hierarchy mode and read me the paragraphs mode or something.

That's my understanding.

As an inexperienced user, my tendency is to just go straight through because it's easier

And I'm usually, I get to a particular section, start voiceover and then only look at the

particular section.

So I'm not to the point of using voiceover for everything.

So another one I see is this like skip to main content.

And I'm like a little fuzzy on this because I see like a lot of, you know, if you go to

GitHub or Google and just hit tab, as soon as you run a search or open a GitHub page,

then you're going to see this text appear that says skip to main content.

Is that a best practice?

And like, how do you create that?

I think the skip to main content links are excellent for primarily keyboard users.

I think that the user that you're trying to help with a skip link is someone who prefers

not to switch to the mouse, but is using the screen.

So maybe somebody who has a really ergonomic keyboard, but due to a risk situation of some

kind doesn't want to be doing those transfers to and from the mouse.

And it's a best practice because you can go directly to the main content without having

to hit tab, which again might be painful for a user, physically painful to get all the

way to the main section.

The way to create the link is you hide it until there's a keyboard event.

And then if the link is focused, you show it.

Now is that like in an L map, would that be in the model, whether there's been keyboard

I suppose you could show it just if it's focused.

So if you're on the URL bar and you hit tab, then it would come into focus and then show,

but you can keep track on the model of whether there's been keyboard, what the last input

If you're wanting to hide your focus rings, although I think focus rings are pretty okay.

You can just show them.

People know that they're there.

You don't have to hide them.

I remember that I had to hide one at one of my previous companies because it didn't look

as great as on the designs.

I fought back against it, but I caved in and I feel really bad about that now, which is

good for the next time.

So these like built in features that are intended to help with accessibility in the browser.

I mean that seems like ideal to me.

If the browser can have defaults that, you know, assuming you don't override them will

help with accessibility.

Like I'm curious with like skip to main content, if that's a best practice, why is that not

built in as a standard?

Because if you have like a main region, you can have like a main tag in your HTML content,

which is generally a best practice as well.

So why wouldn't that be built in to browsers or assistive tools?

I'm not sure if you have thoughts on that, but maybe it will be.

I mean, there's a lot of stuff that people would like to have, but don't.

I also think adding a skip link, it's not that hard.

I mean, compared to a lot of the other features that a person is likely to do, pretty straightforward.

So I would recommend adding it if you've got, you know, a couple of hours, just try.

No, it's, I think the thing that makes me uncomfortable is just not knowing exactly,

like if I could get some sort of checklist, like run a tool, and I guess if you run like

axe, it's going to tell you, Hey, you don't have a skip link and you should add one.

So that's great.

Like I'll, I'll, like it's easy enough to just like let the tool give me a checklist

Well, there is a checklist in the sense of the standards.

Like you have WCAG 2.1, you can go through all of those items and consider them and check

them off for yourself.

There's also, there's templates that exist for if you're selling to, I guess the government

in the US that would help you to write up, write up your alignment in terms of a checklist,

like VPAT, VPATs are those documents.

But ultimately I think because you're talking about users, I don't think a checklist is,

is really going to be enough.

I think that there's a step beyond the checklist that you're going to have to do.

Do you think it's sufficient to run the tests yourself?

Like try to go through the flow that you designed by yourself using a screen reader, using just

a keyword, or do you really recommend to invite people who are used to those workflows to

I think you should probably try to get real user testing whenever possible.

And then I also think that you should design explicitly for the user groups that you're

trying to support.

I don't think replicating the behavior you want for point and click users for other user

groups is going to be as successful as trying to design explicitly for, for every user pattern

that you're trying to support.

Like with the skip link behavior, if you don't have the skip link, your user can still accomplish

what they're trying to do.

They just have to hit tab for the rest of their lives until they get to the content

that they want or use command F or something like that.

And then if you have like a draggable interface, it's going to be pretty hard to replicate

a draggable interface on your keyboard, but there's different, you can design around,

around that pattern.

So I think that's my suggestion is don't try to replicate the experience that you have

and see if it checks the boxes.

Think about it as another design challenge.

Kind of like when you do mobile first, you design for mobile, but then you automatically

get desktop first, desktop supports.

And here you're thinking about accessibility first, right?

That's what I'd like to aim for.

Although since I think many of us have legacy code to support, you're also thinking accessibility

now, I suppose.

Accessibility backwards.

Accessibility fix.

What do you think about this idea of ARIA not being the first resort, but being the

last resort, if you can't achieve an accessible experience without ARIA?

Did we describe what ARIA actually is?

Can you give a brief introduction as to what ARIA is compared to what else we should use?

ARIA attributes are attributes that you add on HTML nodes that communicate to other technologies

like screen readers, something about the page that you wouldn't otherwise be able to communicate.

So maybe if you had a tabbed interface, there's no way to say, I'm a tab section and a tab

And so you could use ARIA to communicate that additional information that says the name

of this tab and this tab is controlling this other section of the page.

It's something of an extension to what's available in HTML.

Is my understanding correct that there's the document object model, the DOM, which we think

about a lot doing web development, and then isn't there the accessibility object model

or something like that, which is basically a similar mapping of what's on the screen

in a way that's going to be interpreted and used by assistive technologies?

And ARIA sort of can annotate the things on your HTML tags in a way that's going to be

used by that accessible object model.

I don't know the details of how the accessibility or how the ARIA attributes work.

I do know that you can see an accessibility tree in a lot of the console development tools

that'll mostly say what a heading is called, information like that.

There's a lot of really pretty good accessibility tooling that's being added to browsers these

days like for color contrast checkers and just there's some neat stuff.

As far as what to reach for first, I think 100% of the time if you can do something in

regular semantic HTML, that's the way to do it.

And I also think often you really don't need the custom widget that it might feel like

It's time for my modal rant.

Strongly opposed to modals.

So pretty much the first thing that I ever learned about web development was that users

don't like alerts and you shouldn't do them, that they're a good way to get feedback, but

that users hate them.

And I was like, okay, don't have popups that make the rest of the page inaccessible.

And then all of a sudden we're like, do have popups that make them less accessible, harder

to use, annoying, have interior scroll.

That's a mistake.

It's wild to me.

And then on top of that, I think often you're trying to do something that you could do without

Like suppose you wanted to delete a post on a blog.

Maybe you hit delete and then these days you'd probably expect a confirm modal to pop up

because you're doing something dangerous.

If you go to your console and write confirm and ask a question, you can get that behavior

like via the alert style.

Perhaps that is better than a modal since it's already built in and then you don't have

to build it and you don't have to worry about focus or the backdrop scrolling underneath

the modal, any of those annoyances.

But if you really suddenly realize that it's annoying to have the page become inaccessible

with a confirmation popup, you could try a different design approach.

After you hit delete, have an undo button that appears on the page.

All of a sudden you haven't interrupted the user experience.

They can still realize they made a mistake and undo their mistake, but you haven't interrupted

them, you haven't caused this huge hiccup.

No bumps in the experience.

But how do you capture their email address when they're like halfway through scrolling

in your article?

And how do you make sure that they accept the cookies?

Two very important questions that I will leave to other minds to figure out.

Yeah, that's interesting.

That makes me think of this.

I don't know, I find myself doing this in Elm often like that Elm makes me rethink complexity

because it makes me look it in the eyes and say, yes, I want this complexity.

Whereas because all of your state and state changes and everything have to be explicit.

So sometimes it makes me reevaluate my designs of a certain UI flow or something and find

a simpler way to express something.

So it kind of makes me think of that, you know, like if you can rethink an experience

and create something that's as good of an experience in a simpler way, why not do that?

It is really hard doing the like, so these things that you're talking about where you're

using ARIA to make highly interactive widgets accessible, like it's extremely difficult.

Would you say that's true?

I don't have experience with it, but from what I have heard, it seems to be quite difficult

to get that right.

Modals are definitely hard.

I think it depends a little bit on what custom thing you're doing, but in general, it's much

harder to get right than it is to just use HTML.

So what are some like common things that require extra care to make sure they're accessible?

Like you know, maybe we can talk about them through the lens of your accessible HTML package.

Can you walk us through some examples?

Like one of the things that you're talking about in your accessible HTML package is like

radio buttons, for example.

What would an accessible radio button look like?

So I guess first off, the accessible HTML package has a lot of stuff in it.

One of the key things that it does is wrap the existing Elm HTML library and then prevent

event listeners on elements where you probably don't want any actual events.

You would want to prevent unclicks on divs, would you?

Yeah, so no more clicks on divs.

Although, you know, if you're doing your own custom modal, you probably do want the backdrop

to be a div and you probably do want it to be clickable.

And then you want the escape button to close the modal.

So the trick you use for that is like attribute never, right?

Or HTML never in some cases?

Yeah, so none of those none of those HTML helpers that shouldn't have event listeners

can have event listeners added to them, thanks to the type system.

Yeah, that's very cool.

And then the other parts of the library include helpers for ARIA attributes.

And I've tried as much as possible to be thorough in the documentation, because I know that

I won't remember it.

So I tried to write documentation that would be helpful for me to understand as well.

Right, so then with radio buttons, you're going to want when you have a radio button

for the radio button to have a label so you know what it is.

And then there's a lot of keyboard behavior that you might not realize exists with radio

So radio buttons have the same name, so they're kind of grouped, the right arrow should loop

you through loop you through those radio button options, the left arrow should loop you through

those radio button options.

And that's the kind of behavior that can be really hard to replicate if you're trying

to make a custom version of a radio button.

So you'll notice if you actually like try to interact with an HTML radio button, that

there's a number of modes of interaction, you've got you're clicking on your label,

you've got you're clicking on the little do hickey part, the click the circle, the circle,

you can click on the circle a bit.

And then there's like the spacebar, there's right and left arrows.

And you would if you were building a custom radio button, you would have to replicate

all of that behavior.

So what you probably actually want to do if you didn't want the default circle is to put

an SVG over the circle.

So you're hiding what the circle looks like, but you're still getting all of the all of

I see people using this kind of technique with like, like list items and you know, unordered

lists a lot where like, if you wanted check marks next to it, then instead of just having,

I don't know, a bunch of divs with a checkmark element in front of it, it semantically is

going to be better if you have an unordered list with list items, and then you have whatever

the like list display none or whatever that is to hide the default bullet points.

And then you can insert your own with CSS with you know, content before that type of

I think that there's a can't you use an SVG there directly?

list item, something list item style, probably list style image seems like a thing.

Unfortunately, you can't as far as I know, do that with the the checkbox little image

or the radio button circle.

I don't I don't know what to call those, which does mean that it's trickier to get like a

custom feel a custom look and feel with the radio button.

One thing to consider when trying to make a custom feel and custom experience is that

part of accessibility includes folks with cognitive disabilities.

When you make your site more custom, and less like the patterns that exist on the desktop

on other sites on the less like the browser that they're choosing to use, you're increasing

the difficulty of learning how your site works, you're introducing new patterns, introducing

new ideas, introducing new icons, and there's a cost to that.

I think if you picture the person, you know, who's the least comfortable on a on a site,

the person when you say button, they say, huh?

It's hard for folks.

Yeah, it makes me think of, you know, just the principle of progressive enhancement,

which seems to be just solid, solid advice.

So, you know, a solid principle to keep in mind when doing web development is, you know,

start with start with something that more or less would if you took out your CSS, and

just had the default built in browser styles, just your HTML, ideally, it should look somewhat

usable and represent what the hierarchy is and that sort of thing.

And then you enhance that with CSS rather than making it usable with CSS, you're enhancing

a usable plain thing into an enriched, more beautiful thing that's still functional.

And that, that principle is going to make you keep you honest about making it functional

Yeah, I love that.

And actually, I've heard that advice for if voiceovers an intimidating thing to try as

a first step, try just removing your styles.

See what, what does your site look like?

Yeah, that's a nice, that's a nice idea.

It also occurred to me that like, maybe something a habit we could build as developers to help

with this kind of thing is to just become more keyboard centric, for example, right?

Like, if we, if we get used to using the tab key to navigate, and we would be frustrated

if we didn't see like a skip to main link, and, and that might raise the bar for our

accessibility in our own development.

I could see that.

Although then we'd have to keep in mind that we weren't overlooking the mouse experience.

That's important to fair enough.

I'm sure there's someone else on the team who will think about that one.

Yeah, interesting.

So do you have any thoughts on forms with regard to accessibility?

Because that's, I mean, maybe that's a whole can of worms, but

what about forms?

Well, for one thing, with the concept of progressive enhancement, like sometimes with, you know,

sort of JavaScript framework based, including Elm web development, it's tempting to just

build an entirely custom experience for submitting data, but not using a form to do so.

Because we have the power of JavaScript.

So we don't need to even wrap things in a form.

You know, we don't want to use this sort of old fashioned serialization format to send

things to the server.

And so like, let's just use JavaScript and hidden API using JavaScript.

So like, is that is that an accessibility red flag?

Like what would, could that lead to accessibility issues?

I haven't looked into forms at any depth.

Well, I'll have to Google that one a little bit.

It's just something I see.

I see a lot of frameworks more and more sort of like react remix and Svelte kit now are

trying to build in some helpers that make it easier to work with sort of progressively

enhancing forms so that if you, you know, I mean, some of them are trying to do it so

that if you turn off JavaScript, you can still do that.

It's difficult to get an experience in Elm where you can turn off JavaScript and have

a usable experience.

But it still seems like having forms as something you progressively enhance, um, could have

some accessibility benefits.

So I'll have to, I'll have to research that a bit.

I was wondering the same thing about forms because I never use the form tag.

That said, I never use any HTML tag except div and span.

Well, sometimes I notice when I'm like, if you wrap something in a form in Elm, like

let's say if you don't wrap something in a form and you just have some inputs, what if

somebody edits some forms?

Maybe you go back to a previous input field and then you hit enter, right?

It should submit the form.

And that's, you know, like you were talking about Tessa, that experience that somebody

might be familiar with a certain experience, whether, whether it's because they're like

a power user who, um, you know, is visually impaired and therefore is very comfortable

at the keyboard or somebody who's like new to using browsers and they're just trying

to use it and they're used to hitting enter into them, enter means go and they're, they're

Whatever it is, that's like the expected experience.

And that comes built in with on submit.

If you hit enter, there's an on submit event, right?

So you have to build in all these experiences.

If you don't use a form, you have to ensure that whatever, whatever things happen when

you, when you hit enter or, you know, perhaps, I don't know, perhaps on a mobile device,

there are certain, you know, maybe the, the keyboard input is going to say a particular

thing and you have to ensure all those things happen if you don't use those built in things.

And you know, if you also leverage certain input types on the keyboard, you're going

to get those benefits out of the box.

So again, it's like if, if the browser platform, if the web platform provides something generally,

you can't go wrong using that thing as a starting point.

I definitely agree with that.

I really feel like HTML is pretty good.

They did some good work over there.

So I was wondering, like, cause I've seen your talks about accessible HTML and I think

they're great and the library looks great, but I never hear people use it actually.

I never hear people saying that they use it.

Do you use it in no reading?

Do you know if other people are using it?

We do use it at no reading.

I wouldn't say that we use it exclusively.

I think part of that though is that we do still have some clickable spans and clickable

So we have the, we have the problem that the library is trying to prevent in some of the

So we don't use it everywhere.

I think it's really helpful for ARIA attributes for adding, adding those important attributes

because otherwise you have to write them out as strings and that's kind of a pain.

So just as a convenience, I think it's really helpful for that.

Your code is a little bit less littered with strings.

Whether you want the event listener prevention or not, I think that that's a taste consideration

to some degree.

And then also, I suppose I should be more specific at no red ink.

We use accessible HTML with CSS, which will enable you to use Richard Feldman's Elm CSS

library as well because Elm CSS also wraps HTML.

So we're doing some, you know, you wrap, you wrap, you wrap.

It's a challenge in Elm.

You get all these drop in replacement libraries that it's just like, it's just like this one,

except there's this one thing changed.

You know, like MiniBill has this wrapper around Elm UI that's like Elm UI with context and

you can't get context, which is like helpful.

But then what if there's another wrapper that's trying to achieve a similar thing and you

can't compose those wrappers together.

So it's a challenge.

But I believe accessible HTML and accessible HTML with CSS both use like the underlying

So they're kind of interoperable.

Is that correct?

Like the type that you're building with accessible HTML is just HTML.

It's not its own HTML type.

It's not its own HTML type.

So if you wanted to, like, for example, if you had like a highly custom interactive widget

that you needed a lot of ARIA attributes for, then you could, you know, you could build

that using the accessible HTML package.

And then it would just give you something of type HTML, the regular plain old Elm HTML

And then you could just include that in a regular Elm HTML page.

So that's sort of somewhat how you use it at KnowRedInk is to drop in or you try to

use it when you can.

And if you can't, you can always sort of use them interchangeably.

That's helpful to know, actually, because I have to admit, I also like I think the that

composability issue is challenging because like I use like I've been using Elm tail end

modules a lot, for example, which uses Elm CSS.

But actually, you could interoperate with Elm CSS and, you know, there's nothing preventing

you from using those two things together.

I think you do want to, you probably want to pick between accessible HTML and accessible

So you're not doing like the too unstyled from unstyled move too much.

But as long as you're decided on whether you want Elm CSS or not Elm CSS, you should be

able to conveniently use accessible HTML or accessible HTML with CSS.

And you can use the attributes without using the HTML node helpers if you're not interested

in the node helpers.

That's awesome.

Yeah, that's a very elegant design.

Okay, I'm gonna have to I'm gonna have to try that out.

Because I have to admit, I've been a little intimidated by the this, this composable Elm

library challenge.

But I think you've sort of come up with a pretty elegant solution to that.

Although having the two libraries that are basically identical to each other has made

me want to update them less, like, Oh, I have to do everything twice.

Yes, definitely.

Do you think it's a good idea to just replace Elm HTML, or sorry, to replace HTML imports

by accessibility in a lot of pages to see where their accessibility issues?

I mean, I don't think it'll get you 100% of the way at all.

I think it's I think you could definitely can do a drop in replace for HTML with accessibility,

the accessibility library.

I think you should also augment that with adding the axe dev tools, ci pieces and, and

do all of the all of the other work that goes along with it.

I don't I don't think that using accessible HTML is sufficient.

It's an option.

It's a tool in your toolkit.

Just like using Elm HTML doesn't prevent you from writing invalid HTML, but it hopefully

help helps you from a couple of pitfalls.

Yes, it's one one step on the on that road, which is which is nice.

I mean, Elm is definitely part of that, that are that robust, robust are.

Yeah, it's like, you're in often often says, like, if you can, you know, it sort of a I

don't know, Maslow's hierarchy of, of type safety or, you know, static guarantees, like

if you can prevent something through types, then that's your number one go to if you can

prevent something through API design through hiding certain things, but the types themselves

could represent impossible states, but the API prevents certain impossible or undesirable

That's, you know, your second thing you reach for.

And then your third thing you reach for might be something like code generation.

And the fourth thing you reach for might be an Elm review rule.

But like, if you can do it any of the other closer to the metal ways, like having the

type make it unrepresentable, you should reach for that.

And that's essentially what accessible HTML is.

It's it's, well, it's it's more using the API design to prevent those impossible states

because the underlying types are the same.

But that's closer to the metal higher up in in your own hierarchy of static checks.

Yeah, it's the one that gives you the best feedback, right?

And the best guarantees as well.

Because there's no escape hatches in the compiler.

So because I know there are escape hatches in accessible HTML, there are escape hatches

So go for types when you can.

So when when you use Elm HTML, the core one over accessible HTML,

I would almost always use it if I was just making a little le demonstration of something

because then I don't have to add another package.

I would also use it if I knew that the thing I was doing was fine.

And then I would probably leave a comment explaining why I think it's fine.

And maybe I'm wrong, but at least that that note is there.

So in the in the modal example that we were talking about, often when a modal is open,

you have a trans a translucent backdrop to the modal that's making the rest of the screen

And a common pattern is that a mouse user is able to click on that backdrop to dismiss

I think this is a nicer user experience since it's easier to get out of a painful, interruptive

experience that nobody wanted ever.

And I think in this case, you could make the backdrop a button or you could do something

with the backdrop to make it an element that expects focus.

But when I think about what the equivalent user experience is for a primary keyboard

user, what I want to do as a keyboard user to exit the modal is hit escape.

I don't want to tab to the backdrop and then click the backdrop with by hitting the spacebar.

That's a weird experience.

Yeah, potentially it also triggers a button or a link.

So I mean, it's just it's definitely odd.

Whatever else it does, it's not intuitive.

So in that case, where I know that I want an event listener on the backdrop, the backdrop

is probably going to be something that shouldn't receive focus like a div.

I don't want to adhere to the idea that you should never, never, never have a clickable

I want to think, can every user that wants to access that wants to exit this terrible

Because I trapped users in the worst UI element that exists.

So in that case, I would use Elm HTML and Elm HTML node for the backdrop and not worry

about about adding that event listener.

I think I would also be willing to use Elm HTML directly if I felt confident that I knew

what elements should have event listeners and what elements shouldn't.

If I had 100% certainty that I was right about where focus was available by default or where

tabability is available by default and was really confident that I was doing the right

thing, maybe I wouldn't be as inclined to use accessible HTML.

Well, not as inclined to use the HTML node constructors and accessible HTML.

I think I would still use the ARIA helpers.

So you've done a lot of work at No Read Ink, Tessa, trying to improve accessibility.

And I know you've really tried to make an effort to keep things really accessible in

the No Read Ink codebase.

So what are some of the lessons you've learned and some of the journeys you've gone through

in that process?

So I think one thing that's been really awesome at No Read Ink is that I've gotten a lot of

support in exploring whatever has interested me, whatever interest I've had.

And I've been encouraged to follow my interests and grow and bring learnings back to the team.

So luckily that has helped me to have room to learn more about accessibility.

The most successful thing that I think we've done so far is started a, well, I suppose

it started as a learning group.

We call it Fab Friday and it's FAB in all caps.

And I have no idea what it stands for.

We didn't write it down.

But why is it in all caps though?

Because it's very fabulous?

It definitely is fabulous.

Yeah, but we started a learning group meeting on Fridays that then expanded into auditing

and improving reusable widgets.

We have actually a package of reusable widgets and we went through those and tested them

and tried to improve them.

And actually using Netlify for that package was really helpful because it made the feedback

loop really fast and we could, a developer could make a PR with an idea with like a,

is this, does this work?

And then the awesome person on the QA team, Christine Horn, who's part of Fab Friday could

help us go through it on Netlify and get that feedback without having to publish it or without

having to commit to it.

Yeah, that's very cool.

And then from there we started working on some of the more legacy code on our site,

what we call the quiz engine.

So that's the part of the site that many, many, many students are using.

And it's kind of been a gradual progression from thinking about ourselves as a learning

group to thinking about ourselves as able to improve widgets that are used across the

So having a big impact, but making small changes to being willing to work directly on the intimidating

parts that get a ton of use and that have been kind of an obstacle when we've thought

about accessibility, because it's been like, well, it's hard because this seems impossible.

So I guess we can't, I guess we can't do it because there's components that have drag

and drop and very fancy formatting.

They're very complicated interfaces, but starting small and working together and being a group

really helped us to build our confidence to where we were able to take on the hardest

So first recommendation is if you can work with Christine Horn, then do go ahead and

But hopefully that will only be available to you if you come work with me.

Is this a time where we say that nobody is hiring?

Oh yes, please take it away.

The other thing that we've tried to do as part of Fab Friday is make cues of tackleable

work, the smaller changes.

And things that are simple and easy to describe, like you mentioned prefers reduced motion

Making those changes has a huge impact for users who are going to have a physical reaction

You can just help someone to not be nauseous.

You can just stop causing someone's nausea.

If you know where the animations are.

So how do you hear about those issues?

How do you detect them?

Is it mostly through user complaints, user issues?

We definitely get user complaints when things are painful for users.

I think some folks on the team are also very attuned to news articles and like new releases

And people will mention those in our topic accessibility Slack channel.

I think a lot of folks are very interested in the topic and will paste links and articles

in that channel.

Our curriculum team in particular is often very interested in accessibility because they're

always thinking about accessibility from more of a content perspective.

If you picture a school, of course, teachers need to be keeping accessibility in mind and

need to be thinking about how to make their classrooms work for the students who are in

their classroom.

Yeah, so I think it's mostly people paying attention and then bringing ideas back to

Something that you said, I think at the reactive talk that you made is that if your accessibility

is terrible on your website, a lot of people won't stay on your website and they will just

go to another product or something like that.

So you won't hear those complaints.

So if your accessibility is very bad, then you as a developer have to step up to improve

I mean, in the case of KnowRedInk, it's the teachers or the schools that subscribe or

adopt KnowRedInk.

So you're kind of forced to get all the accessibility issues from the students.

But I think for other people, other products, that will not be the case.

They will not have that good feedback.

And actually, one of the reasons that I feel so strongly about it being important to make

things accessible is that I feel like our student users don't have as much choice as

And that means to me that it's really, really important that we do right by them.

When people can't choose not to use your product, you have a higher obligation to them.

Man, that puts a lot of pressure.

Well, there's always pressure and we can only do our best.

We can only do what we can do.

Yeah, it seems like the accessibility champion is a common way that companies get more accessibility

But I think more and more, hopefully it'll be built in and we'll develop these skills

better as developers who aren't, maybe it's not our specialty, but we'll be somewhat versed

We're somewhat versed in doing accessible or responsive pages.

I'm optimistic that as an industry, we'll be able to learn more and have broader knowledge.

And maybe have better built ins and things that provide an accessible out of the box

experience that we can leverage by making use of the platform.

So I'm curious Tessa, are there any, is there a little toolkit of biggest bang for your

buck things that you find yourself reaching for and getting the most use out of for somebody

like maybe myself and Jeroen who are not as knowledgeable about accessible experiences?

What are some of your go tos that give you the most benefit?

I suppose, do you mean like a pre made widget or more a blog post or a learning resource?

I mean, any of those, a place to start a thing to be aware of, principle, whatever's helped

I think the principle that's helped the most or the approach that's helped the most is

working with other people so that you're not staring at a spec by yourself and starting

in a concrete place.

I think when we all learned HTML, we probably didn't start by reading the entire HTML spec.

I expect that there's plenty of HTML tags that folks have never heard of and that's

I mean, no worries.

I think as long as there's a moment of, is there a way to do this task in HTML?

Is there a way to do this accessibly?

Searching on the internet for what other people have done, reading blog posts, looking at

the resources that are available for the particular task that you're trying to do, that can help

you to success in a way that trying to learn everything upfront and then remember it until

you need it won't.

And having that motivation too, like if you can somehow see the result of something being

accessible or not, then it's just really hard to be motivated if it's an abstract concept

that you don't know what it actually, what the problem looks like.

If you can look at the problem, then it motivates you to fix it more.

Like if you're trying to use voiceover or trying to use JAWS or...

It definitely gave me a sense of motivation when I was looking at some of my sites and

realizing that the page navigations aren't announced.

When you change the page, you navigate in a link using voiceover and it's very anticlimactic.

Nothing happens.

So it's like, wow, that's pretty important and I'm going to need to...

I mean, fortunately, a lot of companies have written extensively about, for example, like

making Gatsby.js accessible in their page navigations or Reach Router and they've shared

the results of their research.

So I could build that into Elm pages and make it accessible out of the box.

Maybe Ryan can do that in Elm SPA as well.

And then we can...

I mean, that's also a game changer is if we can build these things into our tools, like

the accessible HTML package and who knows, maybe there's some room for some Elm review

rules to help out with the things that we can't check through API design.

Do you think it would be a good idea for the application starters or for Elm pages or Elm

SPA to start with accessible HTML rather than Elm HTML?

Would that be cool?

I feel hesitant pushing...

That feels like pushing my work on people who might not want it.

There are escape hatches and it's just Elm HTML anyway.

There are some slight changes.

It's not a direct copy in all cases.

Like the image helper tries to encourage you to use alt text or to use a decorative image

which has alt text to empty string.

That's kind of the point.

That is kind of the point, but it might make documentation harder.

You would want to say very explicitly that it wasn't using HTML.

I guess I worry about beginners to Elm who are going through the guide and see import

HTML and then it doesn't work.

And then they're unhappy.

At the very least, I think even more so if you're building a site, then accessibility

If you're building a framework, like you were saying earlier, Tessa, that if a user is not

able to choose something else, then you have a responsibility to make that experience accessible

because they don't have a choice.

If you're building a framework, then the things that are built into the framework really do

have a responsibility to be accessible in those core features too.

So I'm going to take a look at making my single page page navigations accessible in Elm pages

because that's like, I mean, Elm pages users don't have an option there.

And so I think those things should really be built in the framework.

And frameworks have a unique opportunity to put a lot of thought into something so that

other people get it for free, which is great.

So that's the ideal.

Well, that sounds awesome to me.

But using the, you know, using voiceover on my computer, which I just hit command F5,

I finally, finally went through some of my sites and tried to like consume them.

I didn't close my eyes or make the pages not visible or anything, but just going through

that experience was really good.

I'm going to be doing that more.

And it feels like less intimidating now that I just tried it to reach for that as a testing

device, just like I would pull up a mobile simulator to make sure that things aren't

overflowing in a weird way and look reasonable on mobile.

And there is a built in voiceover tutorial that you can go through, which might be a

good place to start.

I don't know how to get started on JAWS or NVDA, but if you're on Windows, those are

the things to try.

I saw a video of someone recently using an iPhone with the voiceover and she was like

hovering over a region on the screen and it was reading it.

And she was using Braille to type and was so like way faster than I am to type.

But it was really cool to just see how.

And I guess that's one way to consume voiceover is to sort of like hover over a region and

have it read it for you.

But it's just starting with that awareness is really valuable.

It's amazing some of the physical tools that are out there, like the Braille displays.

And I learned about a cording keyboard recently, which I suppose operates somewhat similarly

to a stenographer keyboard, except that it's more aimed at one hand.

So you're like cording on one hand.

That's awesome.

I wouldn't know where to get started with that either.

It seems like really neat, really pretty neat.

That's incredible.

And also the voice, the speech to text tooling is, I think, much improved these days.

There was a really cool talk at Strange Loop 2019.

Emily Shea talked about voice driven development.

She's a developer with RSI and the whole talk.

She was talking about her process as a developer, but then she's also saying like next slide

to actually control her computer during the presentation.

I think people are going to be probably using like voice assistant devices, sometimes just

for personal preference that they want to use their voice assistant to navigate a website.

And so accessibility is also just being able to access content or sites through more devices.

I think it's like that classic example of accessibility making life better for everybody

with curb cuts.

I don't think I know that one.

I don't know what a curb cut is.

So you know a sidewalk and then at the corner it usually swooshes down to the level of the

pavement so that a wheelchair user can access the sidewalk.

But then if you're walking, you don't have to do a big step up all the time.

And if you have a stroller or a push cart of groceries, it just makes life nicer for

So that's maybe a great note to close on, but before we wrap up, are there any resources

that you want to point people to besides what we'll definitely link to Tessa's accessible

HTML and accessible HTML with CSS packages and all the links that we referred to in the

But are there any other helpful links that you want to point people to?

So I recommend the WCAG web content accessibility guidelines.

That will be overwhelming if you try to read all of it, but if you need a reference for

a particular thing that you're trying to accomplish, I think webaim.org is also pretty good.

There was a good talk at the Juneteenth conference 2020 called Empowerment to the People, What

You Need to Know about Black People, Disability and Accessibility by Angela Hooker.

And then Axcon happens every year and tons of excellent talks from people with much deeper

expertise than me.

And you see, you should definitely take a look at some of those.

And we mentioned Deque with the, they're the makers of the Ax developer tools.

They have a lot of resources on their website and there is a free tier for the dev tools

that you can get started with.

It's a little hard to find on their site, but it does exist.

So you can try it out.

Well, thank you so much for coming on the show, Tessa.

And how can people follow you or KnowRedInk and find out more?

So I believe that my Twitter is T underscore Kelly nine.

You can expect not to hear from me there, but that's where I am.

And then I'm Tesc9 on GitHub, T E S K nine.

And then KnowRedInk, we're hiring.

The constant message.

Come work with me.

Is there a hiring page?

There's a careers page.

There should be a hiring page.

KnowRedInk.com slash jobs.

Well, thanks so much for coming on Tessa.

Pleasure chatting.

This is wonderful.

And Jeroen, I'll talk to you next time.

Thanks for having me.