Mark Boyden: Okay, we like to stay on time here and be appreciative of your time.
Let's see here… so we're gonna go ahead and get started.
My name is Mark Boyden, and I am the IT cowboy here at.
Knowbility, and I'm going to be your MC today. Today, here on Be a Digital Ally, is the AARM framework, what it is, and how it can be leveraged for digital inclusion.
Thanks for being here. Alright, the goals of being a digital ally are to cover the basic skills and the principles behind.
Accessible digital design. We make the digital content accessible to people with disabilities, and this is all about helping everybody else along that path as well. Our typical audience are content creators of all types.
And especially those that are a little newer to. Accessibility.
Let's go to the correct slide. Thanks for letting us be a part of your journey within these meetings and all of our meetings. We strive to be create…
To create inclusive and accessible spaces, to be kind, polite, and respectful to all, and to ensure accessibility.
Knowbility was founded in 1999, so we're a little over 26 years old. As a 501c3 nonprofit based in Austin.
But we operate globally. Our mission is to create an inclusive digital world for people with disabilities.
Some of the programs that we have is the Accessibility Internet Rally. I'll tell you a little bit more after this presentation, because we are gearing up for that, and everybody can get involved.
Xsu is our annual conference on digital accessibility that happens every May.
We're already getting started for next May. Access Works is a program where we bring in people with disabilities who want to be testers and put them to real work with real pay.
And our clients get real accessibility testing. Um, and then we also have a K-12 digital accessibility program that's being led these days by Jan.
Who's here with us today, and then this program, be a digital ally.
Which we affectionately call Bad. Knowbility Services.
We do testing and auditing for accessibility in digital products, websites, and smart apps.
We work with teams to provide leadership and strategic consulting within and without the organization.
We can do custom training programs, and we also have a learning center with some, uh.
Other, uh, ways that you can learn. Accessworks, I told you about a moment ago.
And then we also have the Accessibility Help Desk, where you can contract with us.
To be able to call in and get help with your accessibility issues.
Okay, so a little bit of aspects about how this will roll today. You can ask any time in the Q&A that's down in the menu down at the bottom. You can pop that up.
We'll also be, uh, monitoring the chat, but if you can put it in the QA, great. If not, we'll get you going. If you'd like to ask your question in person, just raise your hand. That's under the reactions down in the bottom menu.
Uh, below this. So, at this point, I'm going to turn it over to Jan.
Thanks for being here.
Jan McSorley: Yeah, hi everybody, um, thank you so much for joining. Uh, we're just gonna have kind of a… A nice conversation today with Denis, who is the…
One of the main brains behind the, um, accessibility roles and responsibilities mapping framework that we're going to talk about today.
And I'm gonna give Denis an opportunity to go ahead and introduce himself, and maybe mention the others who are involved in creating the AARM.
Denis Boudreau: For sure. Thank you. Well, 1st of all, yeah, thank you, and welcome everyone to the presentation. Yeah. This project goes back many, many years.
The first.st actually, no, let me try by presenting myself. Yeah, right? Okay. So yeah. So Denis Boudreaux, I'm from Montreal, Quebec, Canada.
I? I collaborated with Knowbility. I've been collaborating with Knowbility for wow.
I want to say fifteen-ish years in so many different ways. Currently, I also support Knowbility with training needs. Among other things. I know some of you on the call have recognized some names or faces some of you know me for having spent.
1213 years with Dq.
Heading their training service over there.
I am. I've been in this space for about 25 years doing everything from.
You know, editing accessible accessibility for websites to training, to consulting, to.
God knows what else really in this space, and I've been involved with W. 3 C. Since 2,007. So that's been a while as well.
In the Education and Outreach Working Group.
Until it it basically folded and became a series of different.
Community groups, which we'll also talk about as we're going through this. So in a nutshell, you know, that's.
That's me.
Jan McSorley: Okay, and who are some of the other players that you think were key to developing the AARM?
Denis Boudreau: So people that have been involved like there's there's too many people to to name all of them, but the key folks who have been around for the longest, and have contributed.
May be more significantly, are definitely people like Bill Tyler. From optum Jen Chadwick. Currently working with Bmo.
You have people like Sean Kelly. You have people like.
Michael mistak Lewis Phillips, that some of you know here as well.
Has been involved in this. We currently have also people like Mike Gifford Karen akin we have.
Who else? Well, the pressure of not forgetting any name.
I'm forgetting people, I'm sure, and I feel awful about that already. But yeah, a bunch of folks have been involved in this over the years. Some have.
Come and went, and others are still around. But yeah, I'd say roughly.
Close to 12 to 15. People have been involved at this point more seriously than others.
But but yeah, a lot of folks have put their mind behind this as well.
Great.
It is.
Jan McSorley: Definitely an international collaborative effort that came together to create this, so… Um, so could you maybe share your screen, and let's just have you do a quick overview of.
Of where the AARM framework is currently located, so that it's freely available to everyone, and.
While you're doing that, I'm gonna go ahead and put. The, um… the link in to the chat for everyone.
Again, if you have any questions or comments or anything, just feel free to… to express those, and to let us know that you have a question as Denise goes through this.
But this is located on the Web Accessibility Initiative website, um, under their Planning and Policy section, and with that, I'll let Denise kind of go through the resource and how you can use it.
Denis Boudreau: Yeah, so so in in a nutshell.
I'll begin with that. The resource is. Comes from a vision many, many years ago.
The 1st time that I brought that up was 2010. So it's been a while.
It was actually my 1st Csun conference ever.
And and back. Then I was this this guy, this.
Guy from Quebec who had barely been to the United States, had barely spoken English at that point, and I showed up at CSUN with this idea.
Of fixing a problem, really, that I'd been seeing in my own practice here.
In Montreal over the years, which was that. People wanted to work with accessibility, they just didn't know where to start, and they were overwhelmed by.
The quantity of details and criteria and all the things that were complicated.
And I'd been working with this group, and we had started breaking down all the different things that needed to be done by roles, which.
Believe it or not, at that point in time. Was not an obvious thing. Today, you talk about that, people are like, of course, of course you'd do that.
But, you know, 15 years back. People weren't really thinking about it that way yet. We were still at the time where.
If you were taking an accessibility training, people were training you on the success criteria, and regardless of your role.
You had to suffer through, you know, 1.1, and 1.2.1, 1.2.2, 1.2.3, and so on and so forth, A and AA, and blah blah blah. So, it was not customized in any way.
To, um, to what people really needed. And we weren't any better in my business back then.
And… but we started to feel the pressure. And the overwhelm, and quite frankly.
People being bored by the training, because you can see their eyes as glaze over when, you know, if there were designers and we were talking about, you know, semantic structure or, you know, programmatic associations.
Like, they were like, this is not for me. So they were connect… disconnecting constantly. So we started.
And analyzing what was going to be relevant for developers, designers, UI and UX even, content creators, testers, the different roles involved.
And it became pretty clear at some point that. The different success criteria add…
People that were more involved in others in that process. So.
At that point, I had been involved with EO Working Group, Education and Outreach, for a little over 3 years, I'd say.
And so I brought that up to, uh, to Sharon, uh, to Sharon Rush, actually, uh, from Knowbility, but also Sean Henry from W3C.
And we started thinking about what that could look like, and I started.
Playing with that idea within that group. Back then, um, W3UC had this platform on a wiki called Way Engage, so we built a little Way Engage.
Accessibility breakdown, I think it was called. And that, that resource is still available online today, but that was the very first version of.
This resource. And if we fast forward. 7 years… is it season again? 2017, and…
This guy comes up to me, Bill Tyler, and he says, hey, I've been looking at what you're doing, I've been doing something similar for a couple years as well.
Um, I'd love to talk to you about this. So I said, sure. So we started talking, and we found out that we had a lot of, you know, ideas and, you know, perspectives in common related to that.
So we started looking into how we could bring is content and my content together to try and build something else. And I knew from my standpoint that.
My content was not all that great. It had a lot of traction, and people were using it.
But I'd figured out pretty quickly that. Separating the workload by success criteria was not sufficient because it was not granular enough. And you can say, like, for instance, you know, 1.1.1, that's about alt text, so that's going to be content creators, because they're the ones who write the content.
It was more complicated than that, because of course. All text for images, or any kind of text alternative for images, yes, there's a part about creating the content, but there's a part about, you know, defining what the content should be in the context of the webpage. There's a lot about implementation, and which kind of implementation are you doing? Like, there were so many different things that were also part of the process.
That I felt like it needed to be more granular, and I just never had the time to do that, because I was pretty much doing that on my own back then.
But then, Bill shows up, and we start talking about that, and we're like, yeah, we should do something about this. So, and he was with one of his colleagues, Sean Kelly, at the time.
The three of us started meeting to try and build that, and then more people started showing up on our calls on a regular basis.
And that led to this resource. So. This is a labor of love, really, over the course of about 7 to 8 years, that led to disinformation going from one wiki to another.
To ending up on the Wei website, which… quite frankly, was a pretty big deal for us, because.
What's here, by definition, is approved by W3C. Therefore. Like, it made it to a certain level of recognition. And the resources really meant… initially, it was meant as a, um, as a framework for a decision tree, basically.
Which was to say, because our thought… our thinking was, if you're a team.
Uh… like an agency, a team working on digital products in general, and you're thinking about.
Accessibility, and you want to know who's responsible for what, you should have a process through which you could define.
What that's like. So we built this decision tree idea, and the research is really centered around that.
And then at some point, we had this idea that, yeah, but maybe not everyone will want to go through the process of looking at every single task that we defined.
For every single success criteria, because we basically broke down the success criteria.
By however many different granular tasks we thought were relevant. For that one success criterion. So, so…
You know, over 300 of those overall. And uh… and we're like, maybe no… maybe not everyone will feel like going through the very tedious exercise of defining all that stuff, so why don't we build starter kits to people?
Eo at that time, already had these quick tips, or roughly, like, 10 tips for designers, 10 tips for developers, 10 tips for content authors.
So, we meant to go further than that by providing a resource that would be a starting point. And, uh, speaking with Sean Henry from W3C, among others.
Um, the resource eventually went from being a decision tree. Framework to being a platform to help get started.
And the decision tree became this… complementary object, if you will, in that resource, because it turns out that people are much more interested in being given.
A list of things to start with, then actually building their own all the time.
Which, you know, makes… kind of makes sense, uh, when you think about it. So… so that's what it became.
So this resource here, that's the, uh, that's the end result of that process, where.
We basically have defined a series of roles, typical roles, that you, uh, that you would find in any.
Digital, uh, you know, team, uh, working on digital content. And for each of those roles, defining, like, what are the typical responsibilities that they have when it comes to accessibility.
So we've defined that. We defined the success criteria, how they were… are they meant to be broken down.
By more granular tasks, and then at that point, we had a bunch of people doing things, and a bunch of things to be done. So, like, okay, so let's start mapping these things together. And we started putting together this concept, and we had this idea.
Of a racy matrix, for those of you who are familiar with RACI, uh, it's an acronym for Renewed Responsible, Accountable, Consulted, or Informed.
So, we were playing with this idea around that at the same time.
And we ended up with a slightly different, uh… process where we define people who were primary on any particular task, or secondary, or contributor, which is the same idea, basically.
But we took the R and the A, the responsible and accountable, and.
Brought them into a single person, and then people who would support that, or people who would just contribute because they were.
Involved in a conversation, or needed to maybe bring some input so that other people could make the decision.
In a nutshell, that was the idea. And with that, we had all the components to build this resource.
And then we start going through. Every single success criteria, one after the other, for 2.0 at the time.
2.1 came about in 2018. We added data into the process in the years that followed.
2.2 came out last year, and now today, as a matter of fact, this afternoon, we started working on implementing 2.2.
Inside that resource. Um… So yeah, so that's the resource in a nutshell. So, looking at the platform as it is on the website here.
Basically, you have a bit of history. On the homepage, or the landing page of the resource, and then in the sections on the left, you have roles, success criteria, tasks, and decision tree, which is essentially what I've just described to you. So if we look at roles, for instance.
Um, you'll find that… so we've broken this down into 6 different.
Categories of role, if you will. Uh, the business role group, the author role group, the design role group.
Development role group, testing role group, and the administration role group. And for each one of those.
Went and defined the basic. Most commonly, um, agreed upon.
Roles for that. So, as an example, a business analyst under the business role group, or content authoring versus content publishing.
On their authors, or for design, new X versus UI versus UX design versus UX research, rather, and then… and then UI design, visual design as an example.
So on and so forth. And as we were going through this process, of course, some of those roles are heavily involved in accessibility, and others not that much. So when we went to, say, developers, for instance.
A front-end developer, of course, is heavily involved in the process of creating accessible content.
The backend developer? Not so much. So we had to think about that a little bit, and uh… and we wanted to stay away from a very important.
Uh, pitfall, which would have been to say that, you know, this particular role is always involved one way or another, and that was, among other things, the case of the tester.
So, if you're trying to define the responsibilities of a bunch of different people, of course your tester will always be.
Primary on testing. So it kind of defeats the purpose of having a series of roles for someone when you tell, well, your priority is everything.
I mean, if everything's a priority, nothing is, right? So… so it… we had to think about what that meant.
In the context of a tester specifically, but also in the context of a developer, for instance, because.
One could argue that even for color contrast, which is definitely a UI thing in the first place.
Developers need to be involved, because they're ultimately the ones writing the CSS file, or.
Aligning colors with the different assets. So, we had to take a stand on, okay, so.
If someone is always going to be involved, then there's no point in creating a resource around that. It needs to be more specific, more strategic, more surgical than that. And, uh, so as a result of that.
We kept digging further into all of these ideas, and that led to.
You know, hundreds of hours of conversation around, okay, so what does that one success criterion really mean, ultimately? What are we expected to do, really? What does WCAG expect us to do?
Do we feel that that bar is rather low in terms of outcome?
Do we want to go a little further than that? Because we don't have a responsibility as a resource.
Um, and as a, you know, working group, for instance, with, uh, with.
Eo at the time. We did not have a responsibility to create a, like, a normative document. That's WCAG.
Right.
We're creating informative content that is meant to support that resource. And our goal was always… well, my vision for it initially, but then that become our goal as a team, was always to say, you know, there's WCAG that exists.
And for someone who's new to this, or someone who's not particularly well-versed in accessibility, when you read the success criterion.
You know, sometimes it's clear. Sometimes it's definitely not clear, and sometimes you think it's clear, but it's really you're missing the point of what is really intended. So, it's kind of hard to wrap your head around the success criteria themselves.
Which is why the understanding documents exist. But if you're new to accessibility, and you read about.
I don't know, 4.1.2 about name, role, and value, you might conceptually understand what that means.
But if you go ahead and read the understanding document. You could very easily be overwhelmed by the quantity of information that's there.
So there was not a, like, an intermediary step that would help you wrap your head around it more easily.
This is what this resource is about. This resource is about telling you, okay, so here's the success criterion, here's what is a suggestion of what that means for that success criterion, now that you've read this and you've wrapped your head around what that means, from the standpoint of your own role as a.
Ui Designer, for instance, now go and read the understanding document if you want to, but you'll have an angle.
You have a way to attach yourself to it to understand what you're talking about, what they're talking about, and maybe.
Integrate more of that information yourself. So it's like… it's meant like this intermediary between the two.
Jan McSorley: So it's… So it's kind of like you've taken the lens of these different roles.
And interpreted WCAG through those lenses? Is that… am I understanding that correctly?
Denis Boudreau: Pretty… pretty much, pretty much. That's one way to look at it, yes. Um…
Jan McSorley: Okay. So, I have one more question about the roles themselves.
Um, this is… this is a very nice… organized, you know, high-level kind of structure for roles, and…
Some companies will fit straight into this and have no problems with using this. Others will go, well, we don't really have that role, we have a different role called this or that.
Right.
Can you tell me a little bit about what went into making the decision about these roles, and how flexible and customizable they are to different companies in different situations?
Denis Boudreau: It's a great observation. Thank you. Um… Yes, so… so definitely.
If we built a resource intended for the entire world, which, you know, is the case here, and I tell you, well, you know, there are three roles in design, UI, UX, and UX research.
Chances are someone might say, well, you know, my title is this, or this, or that, so there's a bunch of other titles, and people like to make up titles all the time, so it's impossible to just keep track of all of that.
So what we did, and I don't think this is an example.
As we went and defined what we meant by the design role group as an example, we speak to you, user experience researchers, for instance.
We'll give examples of key deliverables. An example job titles for this role. So, you might label yourself as, you know, a usability analyst, for instance, but what you really do is research, like, in the context of how we defined research, hopefully you'll.
Acknowledge that this kind of looks like you, what you do, you might have a different title.
Same thing for UX design. Maybe one of the best examples there. A lot of people call themselves web designers, service designers, or other things. What they do is UX.
But they don't have a UX title. Or maybe in their firm or their organization, you know, someone.
Only does a very specific part of UX, and again, they're kind of broken into a bunch of different responsibilities between different people.
But ultimately, they all fit under the umbrella of, say, UX design, or UI design, or this or that.
Same thing for visual design. Some people will call themselves UI designers, interaction designers, graphic designers. I mean, it doesn't really matter. The idea is that.
We've set a bunch of different examples of job titles that generally fit in this category.
And the idea is that, you know, if you find that what you do or how you identify as a professional in this industry.
Fiss in one of those buckets, then great, easy. If you feel like you're a neighbor between two.
Then the logic is, well, look at both lists, like, both starter kits, which we'll get to in a couple minutes.
Look at those lists as a starting point, and decide, like, what are you really going to prioritize? The idea, like, one of the key ideas behind this resource is.
The acknowledgement that while. Accessibility, WCAG, as a concept is easy enough to understand.
The quantity, the sheer amount of… Details is what makes it very difficult.
Like, understanding a single success criterion in and of itself, or a particular task in and of itself.
It's quite simple. But when you start adding all of them together, it becomes this very overwhelming.
Complex… you know, endeavor that you have to work through.
So… One of the things that we… hold very dear in the concept or the philosophy behind the resources that this is not meant to teach you WCAG.
This is meant to help you take you by the hand, and get you started in doing some accessibility work.
With the hope that as you do those things. Take a very simple example here. Let's say we're talking about UI designers. Of course, UI designers are going to have something about color contrast, use of color, that sort of thing. So…
That may be your very first introduction to accessibility. You say, hey, you know, your color contrasts are a little weak there, we could, you know, work on that a little bit.
You might get a little… a few benefits, and by the way, if you go outside under sun glare, your screen will show, it will pop up more, you know, stuff like that.
And then hope that, as they do this, they're like. Yeah, that wasn't so bad, or… I never thought about that before, and then…
This… you had another thing to it, and you basically start scaffolding.
A bunch of different concepts together, and then they build their own.
Understanding or perspective about accessibility based on their own lens. From a starting point. The goal is not for them to learn about WCAG. The goal is for them to.
Get bitten by the accessibility bug, and say, you know what?
I think that's… I think that's valid. I think that's worth my time. I think I should… pay attention to that, and hope that over time, as they keep adding one piece over the other.
They start having an overarching vision, like a more realistic vision, of what we're talking about, regardless of their role, and it becomes something that they care about.
I've rarely found or met people who were like, you know what, instantly overnight, I wanted to do this, I knew exactly what that was, like, that happens, but it's pretty rare.
What typically happens, especially in business, is that people are… asked, required.
You know, forced, oftentimes, to do things for accessibility, and then at some point, they're like, you know what, that makes a lot of sense.
I want to know more about that. And then they start researching, digging deep into these topics, and then they develop the interest for it.
That's what this resource is really meant to do in the first place. Like, it's helped convert people into believers.
Without them actually knowing. Kind of like, you know, hiding the vegetables in your spaghetti sauce for your kids at the beginning, and then eventually have big, big chunks of.
Carrots or onions that you don't have to hide anymore because they want it. That's the idea.
Jan McSorley: Yeah, that's great. So, can you go back to the homepage? I think I derailed us a little bit when I asked you about the groups.
And could you just sort of talk through the… all of the different components that are a part of the AARM resource on the site, quick?
Denis Boudreau: So, so we, we covered roles already, um, so I would, I would definitely, uh, you know, invite people to go and look at the roles.
To see how this is organized. By the way, all of this is a living document, is a living document, living resource, right? So, and we're very much interested in people joining the community group, which I'm going to talk about eventually, and work on this with us. So, I see, among others, Steven here on the call with us today, who joined us on the community group a couple of weeks, months ago.
And, uh, you know, we're starting to work on this together. Like, we are very interested in having a lot of people join this.
Because right now, this resource is still… the brainchild of, you know, a dozen people. That does not represent an entire industry.
But the vision, eventually, is that as we break that down into the roles, that we would have, you know, a bunch of UX designers who are working together and then brainstorming on these things.
To come up with, and we've tried to do that at this point, but, you know, with a limited group of people.
Write or rewrite, or, you know. Organize the tasks for a particular role in a language that resonates with that group.
So, having, you know, a bunch of developers that the language that we're using, or UX designers.
Is more likely to create resources that are going to resonate with the people that these resources are intended for.
So the more people join, the more we can do that.
Um, so yeah, so roles, basically, is that first part that we define. Um… The WICX success criteria is basically a section where it gives a overview of the different success criteria.
And then breaks it down into who's, uh, who's intended to be a contributor, as an example. So if we look at the first one here.
I'm just gonna do this here. So, like, 1.1.1. Business should be a contributor to that conversation.
The content authors. Who are going to be primary on certain aspects, secondary on other aspects, and contributors on other aspects of 1.1.1, because.
1.1 may be one… your success criterion, but we break that down into, like, 20 different things that you have to think about. So some of them are related to.
Content authoring as a primary, and others, they're just contributors to that. So, once you start breaking that down, it becomes very… well, granular. Uh, visual designers, again. So, different roles, more or less involved. So that's what this resource… this page is about. In this case, we're looking at this as criteria themselves, and say, okay, so in that particular case.
Here's how we feel that it should be addressed. If we look at something like, let's say, uh… you know, at stake, uh, as an example…
In fact, 143 is a good example. So 143 is color contrast. So, if we look at the entire line.
There's only one P in here, and without surprise, that's gonna be visual design, because primary for visual design is to look into that.
But everybody else doesn't really need to be involved in that process, unless in your particular.
Business, for instance, UX as a word… as a… as something to say, or a decision to make on the colors that you choose, but typically developers, designers are going to handle that themselves.
In other cases, it's much more complex, and it's going to be broken down into different people. So that's what this page does at a high level. This, in a nutshell, is the equivalent of what I built in 201.
But the problem with this is that if you only say this and you don't tell people what they're responsible for.
Then nobody is responsible for anything. And if I tell you that, you know, yeah, 1.1.1, that's the responsibility of everyone across the board.
But you don't tell them what they're responsible for. Chances are, things are not going to be done, or things are going to be missed as a result of that. So we needed to go further than that.
And going further than that is the next section, that's the tasks section.
Which is probably the one that interests the most people. This is where we basically looked at everything from WCAG and categorized it into a series of content types or topics. And there's about 10 of them.
Uh, so images and graphs, uh, semantic structure, input modalities, form interactions, CSS and presentation, navigation, data tables, animation and movement, static content, and dynamic interactions. And for each one of those things, we basically have a table like this that says, okay, so.
For 1.1.1, we have, you know, however many, 20-some different items here.
And those are all different things we can do. So as an example, I'm going to take one randomly, this one here.
Uh, so, infirmative images are marked up as foreground images and not embedded as part of a CSS.
So if the image conveys information, it really should be part of your HTML, not part of your CSS.
Of course, you could do that, but then you'd have to create a counterpart in your HTML that actually describes it.
Bit of a pain in the butt. Why don't you just have the image directly in your HTML and do it this way?
None of that's just… if that is prescriptive. It's just one perspective on how you could do this, so that you increase your likelihood of accessibility without creating even more.
Complexity for yourself, or, you know. Challenge for yourself in order to actually do it accessibly.
So, in that particular case, we're saying the primary surrounding developers, but content authoring should be involved in that process.
Yeah, you're going to, you know, take care of the implementation, but you still need the content from somebody else to be able to.
Implement that. Thank you. Um, so, so we've got a bunch of those, right? So, broken down into about 10 different categories, and at the moment, this breaks down every single success criteria from 2.1.
Including AAA. Of course, we didn't put as much effort into AAA, we did at level A and AA, for obvious reasons.
Um… because for most people, that's out of scope, basically. No matter how important they are. But we didn't put as much energy into those things. Maybe we will one day, but for the moment, we really focused on.
A and AA, which already puts us over 300 different tasks, so maybe it's not a great idea to push 3.8 too much also, because we don't want.
We want to avoid the overwhelm in general. But once we did that, once we had that list of tasks, we were like, yeah, okay, so this is great, but if I send someone to that page and I say, hey, look through this.
To see what you're responsible for, scan through every single item, and look for content authoring, because you're a content author, as the primary, and then take that on as your responsibility, again.
Huge overwhelm. That's just too much. So, that's where… that's where the idea of working with the different roles pages came about. So, if we go to the designers, US designers page.
Again, we'll have a couple of examples. Like, there's a… there's a template, of course, here that we're using. So, a summary of the role, different tasks to get started, a case study on how to use the task, some resources, things like that. So we've got that template that we built initially.
Then for one particular role, like UX. Um, like, we came up with this list of 15 different things that we feel.
Are out of 2.1. Are maybe the most bang for your buck.
They might be the low-hanging fruits, if you will, if you're new to UX design. And… So we did that for all four of those roles, main roles, so UI, UX, content, and development.
And, um, and eventually, when we did that, and again, because all of that is grassroots, basically.
We basically look at everything that we had, and there were 6 or 7 of us at the time, and we basically just voted, which ones do you feel are the most relevant?
Very, very informal, not at all, you know, scientific process. We just went, okay, we feel that those are, you know, the good ones.
And after we've done that, we realized it would have been great if.
We had chosen every one of those things. Making sure that there was some kind of, you know, transversality between all of them, so that if you talk about alt text, everyone should have a little bit about alt text, so that it's all part of the same thing, because right now, because we didn't do that, what happens is that every role has 15 different things.
But we may be asking something of a developer. And the counterpart for a UX designer has not been added to their list, so the developer would have something to think about.
But then the UX would not have… that particular thing that they're supposed to do before the developer comes in on their list. So that creates gaps.
So we've identified that as a… in a place for improvement, if you will. So we'll eventually revise those 15 elements so that there's commonality, so that there's no… there's no gap, basically. So if a developer.
Or a UX person has something that they have to work on.
The other one will have the counterpart, so that that thing is actually addressed.
So that at the end of the process, they will have covered that thing. They won't have covered everything, but that particular thing would be covered from beginning to end.
So, little place for improvement there. Um, but to do that.
You have to have everything about WCAG, and since we didn't have 2.2.
Currently in our… in our list, we decided to start by covering 2.2 so that we'd have the complete.
Perspective of WCAG 2.X, and then we'll go back and revisit those 15 keys. But at the same… at the same time.
What we have in there are some of the most impactful things that you can do.
In that role, to get started. And the way that we approach this with people is to say.
You know, don't even think of this as you have to do these 15… these 15 things. Pick maybe one or two in there.
That's it. I mean, just, like, don't… don't overthink it. Take one or two different things, do that.
Get good at it, add another one to it, and then another one, and then again, scaffold your skill set progressively.
Because if I've learned one thing over the last 25 years, is that if you ask someone to do everything.
You're not going to get anywhere. If you give them a small subset, and you encourage them to do that, and they do it well.
Yeah, the… again, the accessibility bug might bite them, and you know, maybe they'll change their mind, and they'll start actually being very invested into it.
Much more likely to… to… bring out success, uh, but it requires you to be patient.
Nothing happens overnight. Like, it may take years, but, you know, every little step counts, and every little step is a win in the right direction.
So that's really the essence of the resource, per se. So, this… this section covers that, whether we're talking UX, visual, content, authors, or front-end developers.
They all have their list of 15 different things to look into.
And, uh, the idea is for someone to just basically take that.
And run with it. And do some… work on some accessibility, and, you know.
Pick up an ID or two along the way. And develop their skill set as they… as they progress.
Jan McSorley: Yeah, so if you're… if you're kind of the… the lone ranger in your organization, and you… you've been bitten by the accessibility bug, as you say.
Um, what are some ideas about how that… how a Lone Ranger might be able to use this resource to help get other people bitten by the accessibility bug?
Denis Boudreau: Um, if I was in that situation, what I would probably look at is the content types that are here.
And say, what can I work on, for instance? That's the closest thing that we have, really, at our disposal at W3C.
To, um, to a… like a design library, like a design pattern library, or something like that.
Design system, maybe. Um, where you can't really… you can't really… look at it from the perspective of, like.
Yeah.
Because, again, most people… are not looking for.
Accessibility answers. What they're looking for is how to make this particular component accessible. Like, they want to know about, you know, their date picker, they want to know about a, uh.
I don't know, like a modal window or whatever. So… the, the, like, the patterns that the W3C, for instance, the AGP, I think they're called.
Accessibility… I forget what they're called. But, uh, the way ARIA patterns that have been developed, W3C.
Are a great place to go for something like that. Um… So, if I'm just looking at accessibility broadly.
I think that, you know, saying, why don't you begin by paying attention to your images, for instance? So, then all of a sudden, between.
All of those things, then you only focus on this one list here.
And that's what you look into. So as a team, for instance, you say, okay, so this is where we're gonna be taking. Some of this is primary with content, some of this is primary with prem developers, some of it is UX design, so on and so forth.
So this is our starting point. Let's do that. On this project, let's just do this. Let's see how that goes. And if we… think that it works well, then we add something else to it. But again, it's this idea of.
Progressively putting things together until you get to a point where you're like, we're covering a lot of.
You know, ground with this. And it's not that overwhelming, after all, because we didn't try to do everything.
We just accepted that we would go slowly. But, you know, baby steps, but in the right direction.
So that's how I would probably look at that. Um.
But yeah, so that's the task section, basically. And then the last section is the decision tree itself.
Which, like I said at the beginning, was initially the core of the resource, but then became.
Some kind of a… of a parallel object that is… that is used for those who feel like doing that.
Where we're basically saying, well, first of all, explaining. The concept of primary ownership versus secondary versus, uh, versus, uh, contributor.
But in the context of a primary. We have this process where we.
Help you define who should be responsible for a particular thing.
So, and it's very simple. It's a yes or no process, basically.
Very simple. Is this tax driven by a business or non-functional requirements? If yes, then the primary ownership should be business. If no, then move to step B. Then you go to step B, and then it's this accountant authoring, if yes or.
So on and so forth. And think of it. And that's how we visually represented over the years. Think of that as a racetrack.
Like a circular racetrack, and you've got, you know. 7 different docs where you can park to change your tires or fuel or whatever.
And, like, are… am I… am I supposed to, you know, go into the dog for… business, or UI, or UX, or this or that, and then you stop there. When you stop, that's your responsibility, that's your task, and the idea was, you'll eventually find one of those things where you're supposed to park.
Your car. And that's… that's where it lands. Of course. Everyone might say, not my problem, so everyone says it's not me, so at the end of the process, the idea is to say, well, if no one has picked up that task at the very end of it.
Then the, uh, the product owner, the project manager, will determine who.
Should be… we should be assigned to, because someone has to take it. Like, it needs to be done. And if no one will claim it, then we'll go to the person who's.
The most likely to be the person to do that. So, at the end of the day, you basically can't just keep going and do laps on your racetrack. You have to stop somewhere.
Um, so that's the idea. So it's a very simple decision tree, uh, process that way. But it has the advantage of having you.
Go through the mental exercise of asking yourself, okay, so color contrast, is that really a business thing? No, not really. Is that a content authoring thing? Nah, not really. Is it a UX? Nah. Is it visual design?
Probably. So, you put an X there, and you keep going. Is it a development thing?
No? Okay, so clearly it's a… it's a UI thing. And you do that for every one of them, and you eventually build your own… description of what the tasks are. So, if you want to tackle the entire thing and build your own for your own organization or your own team, you basically go through all the content types one after the other, so it's a long exercise, clearly, and you define things one at a time, and then you build your own.
List, and the guarantee at the end of that is that if you do this, you'll have lists that are going to be longer or shorter, depending on the roles, but you'll have everything covered.
And as you have everything covered, if you turn that into checklists, and you make sure that all those things are checked before you leave, you deliver your project, then every single aspect of every single success criterion.
That we could think of, because, you know, there could be more, obviously, but will be covered, at least partially.
Which should get you very close to a more accessible website.
Theoretically, I mean, that's the idea, nothing of ever being perfect, but it's going to get you closer to that goal.
And again, that is the intent of the resource. The intent of the resource is not to say, we're guaranteeing you that every set that you build with this will be compliant with WCAG.
But we're saying they're gonna be pretty darn close, or at least much closer than they were if you were just swinging it.
Right.
Because now you have it processed and you can follow. And that's, again, the idea behind the resource.
Jan McSorley: So you have a starting point, and then if you come up with something unique that's not in the resource, do you have an opportunity to join the community group, right? And to contribute. So, do you want to talk a little bit about.
How people can contribute to the work?
Denis Boudreau: Such a fantastic segue. Thank you.
Mark Boyden: Before we segue to that, we do have a question from the last section.
Sure.
Rob asks, how can one leverage AARM to enlist UI designers and FEDs to take on greater ownership.
For accessible interactions and their artifacts, rather than depending on accessibility SMEs to design, develop by defect.
Denis Boudreau: Hmm. Well. The…
I don't know that you could enlist them with the resource, but the resource can certainly.
De-dramatize… And demystify what…
Can or should be done by a particular group. Namely, in this particular case, UI designers, for instance, or front-end developers. So…
I think the problem with accessibility, for the most part, is that.
Most people agree that it needs to be done. But most people also think that somebody else should do it.
And as a result of that, a lot of things don't get done, or a lot of things are just thought about way too.
Far in the process. I remember one of the data points that were shared regularly with… within DQ, and I'm sure it's still shared today.
Was that, you know, 67% of the issues that we were finding when we were auditing.
Actually did not originate from development, but originated from design. So… most things, two-thirds of the things that we see.
Even if they don't feel like a design responsibility, as an example.
Exist further down the line are created by, say, the developers, because of a lack of planning in the design phase. So.
This is… this resource is a part of a bigger conversation about responsibility, about how accessibility is a team effort, about how, uh.
You know, you need to collaborate together to… achieve a certain goal when it comes to that. So, the way that maybe AARM can be used to help those folks is to.
De-dramatize the complexity by saying. Just start with this. Just do that. And if you, as a…
Project lead as a… as a manager, as someone who oversees that team, you accept the inevitable.
Which is that even if you force everyone to do everything, it's not going to happen. It just doesn't.
And you would accept that, you know, from one project to the other, your team will get better, and… from one iteration of your project to another, you can improve on things.
Eventually, you'll get closer and closer to that goal. So, for… I think that to answer the question, you have to first define why UI designers or front developers are maybe reluctant or are pushing back on accessibility.
And work on, you know. Those reasons work on the fears, work on whatever that is that makes them not want to jump on board with that.
And once you've untied that knot, you can say, hey, here's how we can get started.
And even better than that, I would say, here's a couple of things you could consider to get started. Which one do you feel like taking on?
That's even better, because it comes from them. And then you… because it's part of a bigger conversation, right? I mean, you celebrate those wins, you make it very visible.
You make sure that everyone, uh, you know, hears about the great things that were accomplished through accessibility, and all of that, sort of.
Feeds this intrinsic, uh… you know, desire to go further in that way. It's no longer an obligation, it's something that you want to do.
Yeah.
So you have to have that in there as well, and then when those things start coming together.
Of course, a research like this is going to help you, because it basically breaks it down for you in a process, which is a lot more clear than having a bunch of vague success criteria.
To follow, and very long, and, you know, tedious documents, like the understanding documents, which are, again, very important, but.
Really boring to read, uh, as a way to get them excited about accessibility. I've never seen someone read the understanding document for 1.3.1 and say, that was a great read.
That doesn't happen, but it's necessary. But if it's the first thing that you do.
Yeah.
Chances are you're going to be turned off if you actually have something else that's a bit more… easier to… to… to digest.
Then the likelihood of you. Appreciating the understanding document is a little… grows accordingly, I'd say.
Jan McSorley: So, AARM is essentially a tool that accessibility teams can use to sort of.
Bring people into the fold, uh, slowly into the fold, because… I think a little bit behind… what's behind that question, maybe, is an organizational structure issue, where you have a specialized.
Team in place, and everybody just. Sends all their accessibility stuff to them, rather than taking responsibility for it, and so…
Uh, you can use AARM to build those relationships and to help people, you know, take on a little bit of the responsibility and help them… help them understand the importance of doing this.
As a core part of their job.
Denis Boudreau: Yeah, and some ancillary benefit also is that. It creates space for these conversations that otherwise don't happen.
So, if you have a designer, let's, again, let's take the example of Altis for an image.
For years, that was the responsibility of the developers, because that's where the alt attribute and the value.
Were happening. Everyone agrees that you don't want your developer to figure out the alt text, you want somebody else to do that, which typically is the content author.
But if the content author does that in a vacuum. Then they're missing the point. Why did the UI designer choose that image? There was intent behind that, right? If the designer doesn't speak with the content author, the content author doesn't know, so they're going to describe the image for what it is.
But in the context of that particular page, that image was picked because it, you know, it conveyed a certain feeling or emotion, or… or message, so you have to have the designer speaking to the content author, who then.
Yeah.
Turns that into an interesting alt text, and then that information is conveyed over to the developer, who can then implement it.
That interaction there doesn't happen unless you create it. So how do you create it, basically, if it's not by giving people different roles or parts of responsibilities, so that.
The whole thing can come together. And then you ultimately have alt text that is a lot more likely to resonate.
Yeah.
And add to the experience of that page, as opposed to be.
This, again, bland. Very, you know.
Prescriptive description of what the object is, which does not add a lot of value in most of the cases.
Right, so use those defects that you were talking about in your question.
Jan McSorley: To be the impetus for making that change, moving that… into the right role, and have AARM as a tool to help you explain it. I think that's…
It's kind of… yeah, so let's talk about how do you get involved in the work? How do you, uh, you know, contribute to this great resource?
Denis Boudreau: So, very easily, uh, so the, uh, the community group is one of the many community groups that exist at W3C. Uh, you don't have to be a W3C member to be a member of those groups, you can just join, so anyone can join the groups. The way that our group works, we have a meeting every other week.
Um, these days, it's 90 minutes, it's happening on Thursdays, from 12.30 to 2 p.m. Eastern.
This is when we have our calls. Uh, every other week, we have a planning call for that call, so that's the co-chairs. The co-chairs being.
Myself, Jennifer Chadwick, Mike Gifford, Karen Awkins, and Bill Tyler. So, we sort of work behind the scenes to plan the next meeting. We show up to the meeting with whoever wants to show up. Again, Steven today was on the call, a couple of people were on the call with us, and we work on a piece of this to.
Bring it further. And, um… So, so the easiest way to get involved, really, is just to go to this page and click the join, uh, the join or leave… well, I guess…
I guess you don't have to leave option if you're not a member already. I guess it's a join community, and if you're… if you're not yet a member.
Um, but you hit that button, and then you follow the process of joining the group.
And then we're going to, uh. To get in touch with you, give you the information that you need to join us on those calls. Uh, we have two different mailing lists. The way that W3C works for that, there's an internal and external mailing list.
The external one is archived for everyone in the world to see, as long as they have the address for it.
And the internal one is more for the group itself. Where we share things like the Zoom link and stuff like that. But it's as simple as that. It's really that simple.
And there's no pressure to perform or anything like that. We understand that this is… In a lot of ways, this is like a hobby for folks. I mean, this is something that you work on because, you know, you're a bit of a geek and you like accessibility, and you want to contribute something of value that has an impact, that can enter an international impact. Um, but you show up when you can, and we were happy to have you when you're there, and if you can't make it, that's fine also.
You get caught up the next time that you show up, and the project keeps… keeps moving forward.
With whoever is available to help do that.
Jan McSorley: So, speaking of… speaking of accessibility geeks, you know, accessibility guidance and tools like this, um, come through a lot of collaboration, a lot of.
Co-laboring, co-writing. And I understand that you recently co-authored a new book. Can you talk to us a little bit about that?
Denis Boudreau: Oh, yes. You're really good at segues, you. Um, yeah, so, so, so last week, as a matter of fact, so this book here.
Inclusive Design for Accessibility, uh, was published. Very happy about that. Um, it's 12 people coming together. It was, uh, so it's published by Pact Publishing.
They knew, uh, my co-author, Dale Cruz, because Dale wrote a book on HTML5, about 10 years ago, so they were already.
In a bit of a relationship together, and there was an opportunity to write a book on inclusive design. He reached out to me, so we.
Talked to a couple people, recruited 10 other folks, including, among others, Jen Chadwick from our group.
As one of the authors, and we all took a chapter, basically, um… defining what accessibility of inclusive design is, really. Starting from.
Starting from the end user, starting from the person with a disability, speaking to that concept and progressively growing into different aspects, like design, development, so on and so forth, I write the last chapter, which is more about.
The organization and the culture around inclusion, so we really begin from, here is what.
Why we talk about this, to here is how you can implement that into your place of business, into your organization, into your communications, and in the middle, we basically cover.
Everything from the lifecycle standpoint. So it's a really complete book.
On all these topics, and uh, yeah, came out last week, um, available on Amazon, available.
Couple places like that. Um… We've had great feedback so far. Thank you for mentioning it.
Jan McSorley: Sure. All right, so, um, looks like we have a… Question here says, this is from, I think, um…
It says, how… have many… have more cross-functional accessibility roles been considered in roles and responsibilities?
Apart from the admin role, for example, accessibility champions. Will there be some sort of guidance to encourage cross-collaboration between roles?
To achieve accessibility with a more holistic, less siloed design approach.
Denis Boudreau: Yeah, the answer is yes. And the answer is also, we just don't know who's going to do it and when, really. This is a community group effort, right? So…
It's volunteer work, so things… progress at the level that they progress, which sometimes is very fast, and sometimes is.
Painfully slow. So, it depends on people's availability and what we can afford to work on at any given time. But yes, the vision for the resource is to keep growing in whatever areas identified as being.
You know, the most pressing one. Um, right now, that's covering 2.2, as an example.
But once that's done, there's a bunch of ways in which we could expand that resource. One of the things that I have in mind, for instance, is have a dedicated page for every single task that we have, so.
Hundreds of them, where you could go and say, okay, so from the standpoint of this role or that role, this is what that means. Here's how you can work together to do that, and create that.
That, you know, collaboration that you're talking about in this way. So, but that's just one of the ways.
There's a huge portion that should… that needs to be created for the testers, among other things. Right now, what we decided was that.
There was no point in having the testers involved in every single test, because again, if everything's a priority, then nothing is.
So, we've basically siloed the testers. As a parallel responsibility.
That is yet to be defined. Like, how do we want to do that? Are we going.
By automation versus manual testing, are you doing… you know, whichever way we would want to do that is not… is yet to be defined.
Because there's so much that could be built into this, but… you know, we just need volunteers to help us with that, so if there's anything that you feel particularly strongly about, and you'd like to work with.
Other people who care just as much as you do about helping.
The web… the… the… digital in general, be more inclusive.
This is a great place to do that, so we'd love to.
Have you joined?
Jan McSorley: Yeah, I… what I like about Emily's question is, um, that they're talking about accessibility champions, which I think gets… actually ties into the previous question.
Where you… accessibility doesn't work well in isolation. You know, it needs to be integrated, you need to have these champions, so I love the fact that you're looking at.
And how can we do more cross-functional collaboration? And I think your table already.
Sort of addresses that to some degree, where you're talking about who's the primary, who's, you know, who's a contributor, etc.
Yeah.
But that's an excellent observation, and definitely that's the message, I think, of AARM, is that.
Accessibility is not… is not a siloable, um… discipline.
Denis Boudreau: Right. I mean, the underlying… Right, exactly. The underlying concept behind this is that it's not one person's responsibility, it is shared across a life cycle.
Yeah.
Now, we did talk about the accessibility SME at some point, the accessibility SME, the expert at some point, and sort of stayed away from that because.
That… it… it, um… it keeps the concept of the accessibility person alive in this, and we're trying to.
Kind of squash that and say, yes, you can have someone who's very well-versed in accessibility, for sure.
They can be your… they can be your… your… you know, your… your North Star, if you will.
But you need to take ownership. You need to do things. This is not only them, it's also you and your role. So this is what the resource focus is on right now. It doesn't mean that in the future.
We can find a way to have that accessibility champion being part of the process.
And I… I totally see how that person… that role could be there.
Yeah.
But it would be treated the same way that the… in a similar way than the… the tester is dressed right now, where.
It's not the doers in particular. Like, right now, the focus is really on those in the front lines, in the trenches, if you will.
Doing the thing, building the thing. And everyone around that.
Yeah.
As a role to play. They all have different responsibilities that are supporting or.
Very important to the success of the effort. But they're not involved directly in the creation or.
The, um… or reaching, you know, the intent of the success criteria, they're supporting one or another.
So, it's a different aspect of… this entire spectrum, if you will.
Jan McSorley: Yeah. Yeah.
Yeah. Well, thank you so much, Denise, for sharing this with us today. We are at time, and.
We're grateful to all of you for joining us today. You've got some wonderful resources that you can go back to. You've got the AARM resource itself, the community group. Please, please do consider joining the community group and contributing to the work.
And then, of course, make sure you get your copy of Inclusive Design for Accessibility.
And read up on that as well. So, thank you so much for sharing all of this wonderful wealth of knowledge.
Denis Boudreau: Yeah, thank you for having me. Thank you for being here.
Mark Boyden: Yes, indeed. Thank you for… both of you, for an engaging conversation. This kind of reminds me a little bit of the Charles Osgood responsibility poem.
Uh, where about everybody, somebody, nobody, and anybody. We've all seen and heard that one, but uh… getting everybody to kind of agree on things. Just wanted to let everybody know.
There is an opportunity to engage with Knowbility here in the fall in our accessibility internet rally.
And this is where we bring together web developers who want to increase their accessibility skills.
To participate in a hackathon, to build a website for a non-profit, non-governmental organization.
Or an artist, or musician, we… The registration deadline is coming up September 13th. It is an 8-week accessibility program that you do on your own time.
And the winners will get tickets to our XSU conference, which is worth almost $1,000.
For each person. Find out more information at Knowbility.air. I'm sorry, not air, or Knowbility.org slash air.
Um, and then you can stay connected with us, you can subscribe to our newsletter, this stuff's all on our website, too.
Find us on social medias at Knowbility, and if you'd like to email us about this, or have follow-up questions, events at Knowbility.org.
Finally, we truly appreciate hearing from you, especially the feedback about this program.
How well it met your expectations, and what we might do in the future. So, if you'll take just a moment and go to Knowbility.org slash.
Bought a survey that's B-A-D-A survey, and share that, or if you're so inclined, we always kindly accept donations to our cause.
We'll be back next month with another great program, and we'll be in touch.
Thank you again.
Jan McSorley: Yeah, bye everybody!
Denis Boudreau: Thanks, everyone. Bye-bye. Take care.