Be a Digital Ally: Straight Talk What Disabled Users Want You to Know When Designing your Product

>> Sharron Rush: Okay.

So welcome to Knowbility's BADA, Be a digital ally.

And.

You can just move them along, Mark, if you would, or.

Today, we're gonna.

Talk, about.

Being a digital ally. That's the theme of our presentations, and.

We had this idea of.

Actually,

Letting people who weren't able to attend AccessU see, some of the highlights of the best presentations, and one of those this year was straight talk. What disabled users want you to know when designing your product.

By Amy, Amy Mason, and Bruno Torquato. So our ageNDA tonight.

Will be to

I'm gonna do a brief.

A brief intro of Knowbility.

We'd love for you to introduce yourselves in the chat. Put your name, your organization.

What you're interested in, because we're gonna.

Kind of look through our AccessU recordings and figure out based on.

What our audience tells us is of most interest, what to bring in next month, and the month after that. So your name, your organization, your interest areas. If you put those in the chat.

And then I'm gonna talk a little bit about Knowbility, who we are, what we do.

Introduce our presenters for this evening's presentation, and then we'll see an edited recorded session.

From AccessU in May of 2,020.

And then the best part, I think, is the live QA. That we get from with the presenters, where we get to talk to them and hear their perspective of the presentation they've made to us, and then we'll do a little outro and.

Thank you all for being here and for being such great digital allies.

Knowbility was founded in 1 99, and we, our purpose there was to raise awareness and skills and active engagement in the whole issue of digital equity and equal access to technology for people with disabilities. At that time.

The accessibility was

Kind of a rare.

Conversation piece. People were still learning how to use the Internet and how to.

Make the most of the technology.

The desktop technology that most people used and.

Accessibility wasn't nearly as.

Forward as it is now, so we like to think we had something to do with that.

Our mission is to help create an inclusive world for people with disabilities.

We do that through 3 related sets of services, raising awareness of the fact that it's an issue.

Why it matters.

And one of the ways that we're really pleased that we get to do that is with what we call air or the accessibility Internet. Rally.

And that's something that's ongoing. Right now, if you go to the Knowbility website, it's right there, front and center.

We're recruiting teams of people to participate and learn more about accessibility. Join up with the community, be part of a team that builds an

An accessible website for nonprofit organizations. And then, of course, you have the chance to win glory and.

Be 1st in this competition.

That's air. So learn more about it and register. Now on our website, that's just one of many of our awareness programs. But I wanted to highlight it because it's active right now.

And then we do a lot of education, including our annual AccessU, which is.

What this is, part of.

And we do that every may in.

Austin here in Austin, but we've also.

Really perfected during covid the hybrid aspect of it. So you can attend from wherever you are.

That's every May. So keep an eye out for that.

And then we do direct services to business and government agencies, including audit and advisory services.

And there's, of course, more information about that.

On the web. So we've been doing all this for 25 years, and.

Really welcome the fact that y'all are joining us tonight for this.

Today's presenters are Amy Mason and Bruno Torquato, and they both work in accessibility at UKG.

The agency. U Kg. And they're pictured here.

With their unicorn headbands from AccessU. We had a happy hour called.

The accessibility unicorn, because we felt like a lot of in the career world.

A lot of people were looking for just one person to do all the accessibility of an entire agency or organization. So it was a themed happy hour Atsu and

Amy and Bruno are pictured here with their unicorn bands on.

And they're gonna be.

They're gonna be the presenters in the slides that Mark's gonna share with you here in a minute.

Now we're gonna play the video and you're gonna get to see it for yourself.

Bruno Torquato: Our talk is called straight talk.

Amy Mason: What people with disabilities want you to know when designing your product.

Bruno Torquato: And so.

Nice to meet you. We're Bruno and Amy, or Amy and Bruno. We're both cat people.

Amy Mason: Yes, we have our selfies here with our cats on the left. You've got me kind of peeking in while.

My Tabby cat, who's a great tabby, has got the majority of the shot.

Followed a little bit lower by who is technically a TUXedo. But you can only see her little black face.

Bruno Torquato: And you see me here with my my stepdaughter's crunch and Remy.

They're also taking up the majority of the frame as they should. I also got some cat socks on. You may notice.

But yes, this is us.

It might be worth the humor that you know we've got. These delightfully queer people having a session called straight talk is not lost on us.

If if you can't see us. I'm wearing what I would describe as business attire from the feminine section, but definitely somewhere in between masculine and feminine, and I'm wearing makeup.

Amy Mason: And I've got a bit of an undercut haircut. So that's a little more of a masculine look, a blazer with little speckles of all the colors.

With a lavender blouse and a little bit of

Trimmed chin, hair.

So, yeah, neither of us are.

Exactly the straight talk people. We're the queer, straight talk people.

Bruno Torquato: So why, you might want to listen to Amy. Want to tell him a little bit about yourself.

Amy Mason: I have been blind all my life. I'm also near divergent ADHD.

Probably autistic. So I've been in the accessibility space as a user from the beginning.

And I've also worked in a number of organizations where I've had the opportunity to talk to designers and developers.

Educators and creators and users.

About accessibility, everything from instructing someone on how to use the iPhone with voiceover.

Through working with developers to create accessible caleNDAr with staNDArds, bodies.

Around understanding the realities of how the staNDArd say for epub is being used and made available.

In

Classroom epub readers, or even the ability to create accessible epub from a blind person's perspective.

Bruno Torquato: And some caveats.

Amy Mason: Yep, there are some caveats as wonderful as I am.

I mostly have had experience with people.

Who identify primarily as blind as their disability.

Most of the people I've worked with have been adults, or at least teenagers.

I have really only worked.

In.

A environment where most of the people I've worked with already know that they have a disability and came in through a system where.

They were being assisted with that.

And.

I also primarily have worked with people who are.

English, speaking as a 1st language, and working in the context of being here in the United States.

Bruno Torquato: And me. I'm Bruno. I've had about 16 years of broad experience in the web and software industry.

A big part of that has been focused on accessibility.

But I've run the gamut across the entire stack. So I've done software design some development.

Usability, testing, planning, and facilitation. I've done some.

Quality. Some Q&A. Work as well, and more accessibility than.

I'm.

Honestly comfortable, doing.

Recently, we've done a lot of work at UKG trying to grow the program. So a lot of the focus recently has been on teaching accessibility, principles, and growing the overall maturity of our enterprise system. So.

Some caveats is.

I'm not really a daily screen reader user. I'm more experienced in making accessible software than I am in using software. I've worked mostly with people cognitive and visual disabilities. So I definitely have some.

Some gaps and biases. Of course.

And I've worked.

Pretty much exclusively in this sort of corporate business, to business environment as contrasted Amy, who's done a lot more work directly with community members, and with teaching and things like that, much like Amy, though most of my professional experience is limited to English, even though I speak a few other languages.

But yeah, that that aside, I think we can be reasonably trusted. So let's get on with the actual info here.

We're so this is part one. And it's just like a brief primer on interactions with disabled people.

Amy Mason: So here's the thing.

I promise.

Most of us don't bite.

We are at the end of the day, just like y'all.

We.

Are just people. So.

Treat us like other people. Ask questions, get to know us.

And we'll talk a little more here in this section about what that looks like.

How to speak about disability, etc.

Bruno Torquato: Yeah. So we're gonna start off talking about language.

Specifically, we're going to get into a little bit of the identity 1st person 1st debate.

And I guess that's the 1st thing to note is that there is debate. So you want to take that Amy.

Amy Mason: A person. 1st language kind of came about as an attempt by.

A lot of folks who were well-meaning in trying to explain.

That someone with a disability is a person. First.st

So examples of person language. It's often used in academia. It's often used in medical contexts.

Some examples that are actually.

Relevant. Here might be a man who is deaf.

A woman who is blind.

A girl with autism.

A boy who uses a wheelchair.

So you are putting the person.

Identifier before the quote, unquote condition identifier.

And.

Things are a bit mixed as to who wants to have that happen, and who doesn't.

Identity. First.st

Are we ready for that slide?

Bruno Torquato: I wanna.

Also just mentioned the brief quote that we have from national disability and journalism.

So I'm just gonna read this directly.

The past. We've encouraged journalists and others to use person language. This is what Amy was mentioning now.

As a default.

Even with the caveat, that this does not apply to all we've heard from many people with disabilities who take issue with that advice for us. This really emphasizes the fact that no 2 people are the same, either with regard to disabilities or language preferences. So that brings us right to

Amy Mason: Identity first.

Identity 1st tens, and I won't say always.

But certainly in the circles that I've run in.

To be the preferred option for a lot of folks with disabilities that once again I've worked with.

And known. For example.

You've got folks from the deaf culture who are actively proud of their deafness, and they would.

Probably be a little bit upset if you called them always the man who is deaf.

They would prefer to be known as a deaf man.

Certainly I, as a blind person, prefer to identify as blind.

First, and not just.

Person who is blind.

I know that in the neurodivergent community there is a lot of preference for the identity.

Before.

The.

Person.

And really just from a functional level.

Although sometimes it's.

Legit. I think most of us mix it up.

It gets really awkward.

Because.

Person 1st is not how we handle anything but disability.

You don't generally say.

The woman who is.

Gay, or.

The man who is Jewish.

Or the girl who is black, you usually would.

Use the identifier first and like those other identities.

It's not all of what defines us as people with disabilities, but it is.

A major part of our lives, and it's part of our identities as people. And so we often.

Want that included, especially if that's what we are specifically referring to.

Bruno Torquato: So that takes us right to the continuation of that quote that we had from the National Center on disability and journalism.

And it ends on a note here where it says, and so we're no longer offering advice regarding a default.

Instead, we hope you'll double down to find out how people would like to be described.

We'll also include some guidance. But again, we encourage you to confirm on a case by case basis. So what this means for you, if you're running usability, research is.

By all means you should be asking. You need to ask your users. Another thing that you definitely want to do is pay attention. How people talk about themselves and do some mirroring of how they speak about themselves.

Take note of what type of language they use, whether it's identity 1st or person. First.st

While they're speaking about themselves and mirror, how they do that.

Moving right along. We have a few more tips on etiquette.

And this is about using common terminology. So.

Amy, you want to take.

Amy Mason: Sure.

So when we talk about common terminology for disability.

There is a lot of stuff that is generally.

Much universal, at least here in the Us.

For instance.

Hey, Bruno, did you see that movie last night?

Bruno Torquato: I did. You see it?

Amy Mason: I did. It was great.

Or did you hear the gossip.

Bruno Torquato: Is that what you heard?

Amy Mason: Yes. Oh, my goodness! Isn't that great?

Bruno Torquato: I'm a little embarrassed to talk about it. Oh, I know, but it's so funny.

Bruno Torquato: You read that book.

Amy Mason: Absolutely

I saw you walking with your friend in the wheelchair the other day.

Bruno Torquato: Yeah, we took a walk. We just had to take a breather, you know. Just we walked around the campus a little bit and talked about things. It was great.

Amy Mason: Good.

So I mean end of the day. We're using the same language. Y'all are.

And so it kind of gets uncomfortable and weird for you to want to try to think about it, and for us to kind of.

Deal with it when it's like.

Did you hear of that movie.

To someone who's blind, or did you.

No, we saw the movie, I mean.

Not visually. But whatever that's the language that we're all using will.

We're just gonna be just as happy and comfortable using the same language.

You know.

Bruno Torquato: Don't make it weird. Don't pause and apologize. I'm sorry you didn't see. What do I just talk like a human.

And again, like we mentioned before, something you'll definitely want to do in these cases. Pay attention and mirror. How somebody talks and make sure that if there's anything that you notice about how they talk about themselves.

That you run with that.

So yeah. So when you're talking about disability, you, you might want to ask people how they identify. So like for yourself, Amy.

Amy Mason: Like, yeah, for me, I identify as a blind person. I do have.

Some vision that I do use so often if I need to make it clear.

That I may be doing something visually. I will say I'm a low vision, but.

Have I identified? Personally, I will probably just initially come out and tell you. Hi, I'm a blind person.

If that is relevant information.

Or if I'm writing about myself, for example.

You.

Will want to listen to how people represent themselves, because, like I said, I call myself.

Blind or low vision depending. But blind is my.

You want to avoid.

There's a lot of terms that get a bit weird.

For example, in the blindness

field. Legal blindness is a very specific legal definition.

Really, we don't care if you're legally blind unless we're social security or the DMV.

Bruno Torquato: And if you want to get sincere user feedback, the last thing you, the last thing you want to evoke, the last vibe that you would want to go for is.

The SSA. Or a DMV. Right like.

You want to elicit, you know, warmth and real like sincerity from your users when you're researching and interviewing them so.

Definitely. Don't come off like you're the Social Security Administration or the DMV.

Amy Mason: Don't worry. We will be most warm, and sincere, if you do.

Bruno Torquato: Maybe in a different way.

Amy Mason: Yeah, maybe not in the way you want. Might be a little more warm, like a jalapeno than a warm hug.

Bruno Torquato: That takes us right to some specific terms that you.

Probably want to avoid. If you're talking about disabilities, one example would be wheelchair, bound or hearing impaired. You want to talk about that a little bit more.

Amy Mason: Wheelchair, bound.

You want to avoid terms like that, because.

The person is not tied to the wheelchair.

The wheelchair is a tool they are using.

It gives them freedom. It gives them agency, ability to move through the world.

It's not something that they are forced into.

It's something that they're using to give them freedom. So you want to use.

Terminology that shows that it's a tool being used. It is not a restraint on the person.

Likewise with well, not likewise. It's a very different topic, but.

There are terms that are just kind of out of fashion. Now, for a lot of reasons, hearing impaired tends not to be used as often as a hard of hearing or deaf.

Because it has.

Gone out of favor partially because hearing impaired is kind of just icky.

Bruno Torquato: Sounds kind of medical, doesn't sound very casual or personable.

Amy Mason: Yeah.

I mean, and if someone's using that terminology for themselves, that's a different issue.

The new mirror once again what they're doing, but.

By default.

Kind of the terminology, that is.

Common.

Is going to be things more like.

Hard of hearing or deaf for folks with.

Who are deaf.

Blind folks. A lot of us are using terms like.

Blind. I've heard low vision more regularly, but I'm sure there are other terms. People are still using.

I'm not going to speak directly to that, except to say that personally, I've kind of taken that on when I need to explain further.

But there are some words that pretty much anyone in the disability community is going to shrink back a bit.

Bruno Torquato: Terms you definitely want to avoid.

And we have a little symbol on the screen, you know, like the non-smoking symbol like, Don't do this.

Amy Mason: So.

One of the big.

Handicap.

Unless you are specifically referring to a law or,

a place that is dealing specifically, that is, using that terminology. Still.

I cannot think of anyone I know personally in the disability community that would prefer,

or actively use the word handicapped to refer to their disability.

I just haven't seen it.

It may exist, but I don't know.

I would avoid.

Others that are uncomfortable tend to be the kind of thing that is,

Inspirational.

Or softens, disability.

Differently abled.

Special needs.

Handy-capable.

Please.

I will get down on my knees for this one.

Never say handy-capable.

It's just bad. It's.

It feels kind of infantizing. It's.

Kind of disregarding our lived experience.

A lot of us have grown to, and I once again I can't say everyone, but a lot of us have grown to.

Feel that our disability is something that.

We are,

proud to identify with, because it is part of who we are.

And.

We're proud of the things we are doing as we live in the world, and that's just much a part of us as our race or our gender.

Lot of other expressions that are just part of us. Characteristics.

So using that language tends to be friendlier.

Bruno Torquato: Yeah, and I would be remiss if I didn't. Meant at least call back to Merrill Evans yesterday.

Saying, don't make assumptions right?

Like with all of the things we've been telling you.

The number one takeaway should be that you should be asking your users and paying attention to how they talk about themselves. These are just some like general guidelines.

Maybe those people exist like Amy mentioned. They may be rare, but they might be out there. So...

Always, ask.

Similarly, we want to talk a little bit about some interactions, especially if you're going to be doing research. And you want to ask some pointed questions about some that you want to bring to your team with some real takeaways.

So there's some tips about that, right like, for example, you'd want to ask about.

How the person uses their tools, rather than go on to lengthy discussions about their diagnoses, or what they can and can't do.

So you want to talk about that a little bit?

Amy Mason: Absolutely.

Very simply.

Medical history can be a real, touchy subject.

A lot of people feel that's private. It does not matter to you.

How I ended up developing this disability, whatever it is.

That's mine, not yours.

And frankly, you know there's some folks like me who I will gladly tell you.

However, do you have half an hour for me to explain all the nuances.

Or would you like to get onto the user research?

Because if we want to get onto the user research, we care about the tools they are using and the ways.

That they interact with our product.

Which means.

How do you do this thing?

How do you visit that website? What tools are you using to.

Access this experience in the world?

And.

And in the same way.

It's very muddy when you ask about someone's capabilities.

1st of all capabilities change, one day my eye is much fuzzier than another.

One day I might print another day. There's no chance on earth.

They're trying to get all of that kind of concisely down isn't going to help you nearly as much as oh, yeah, I'm a jaws user most of the time. So sometimes I use.

Windows, high contrast, mode, and.

Smartenvert or dark mode on my smartphone.

Bruno Torquato: Yeah. So for the researcher, some takeaways from that is.

You know, don't focus on asking stuff about the person's condition.

Ask more about the tools that they use and what you really want to take away to your team. So.

And you'd want to ask questions like.

Tell me a little bit about what tools you use to access the web or web apps, or your phone. Tell me about some of the settings that you use.

You know, or if you're about to show them a prototype, you might ask something like, explain your experience communicating in an environment like this that I'm about to show you.

So you would want to shy away from.

Asking like really pointed questions about someone's medical history or.

How they got to where they were just not going to be relevant to your study. And it's not going to give you.

Actionable takeaways when you're designing things.

Amy Mason: And honestly, it's going to waste your time.

Even if the person wants to explain it, it's just too generalized and not focused on where you want to be.

And it can make conversations really uncomfortable.

Bruno Torquato: Bet.

So that takes us to our next section. We're gonna talk a little bit about planning your inclusive user research. If you know a little bit about how to talk internally at your company about this topic. You might start bringing this up, and you might even convince somebody that you should be doing some research, and then they'll go along with it.

Amy Mason: Something about us, without us,

Bruno Torquato: Absolutely.

And so the idea would be well, really, we also heard yesterday nothing without us. Period right like I like that. Take away from yesterday.

Whether it's about us or not. Nothing without us.

Always included people.

That's a really good takeaway.

So maybe you've convinced someone. Or maybe you need help convincing somebody because you're in the really early stages. So that's what we're gonna be focusing on. Now.

Biggest point that we want you to take away here is that you should be doing this research as early as possible.

So the best time would be.

Right when that light bulb goes off in someone's head, and they 1st conceived of the idea.

Because you don't want to build it on shaky fouNDAtions. You don't want to.

You don't want that idea to develop through multiple phases of development when it didn't make sense. In the 1st place. So the earlier you do the research like, with all UX research the better. This is especially true. If it's hardware products. We've seen a lot of.

Hardware products out there, looking to serve the disability that.

Frankly, just.

Come out of nowhere and then flop because they're not really solving a problem. So tell us a little bit about some of those things.

Amy Mason: Absolutely.

One kind of famous example within the blindness community is all of the folks that want to build the replacement for the guide dog, or the white cane.

I have,

heard of, though. Never actually got to see a prototype that someone came in with once that looked like a hula skirt.

With little fibro.

Tactile whiskers that someone would wear out around themselves, looking thing so that it would hit.

The table in front of me before I did, and it's like that is not my look.

Not to mention. I am still gonna go tumbling down the stairs.

Likewise you're looking at a lot of the vibro-tactile canes that are happening right now.

And yeah, they might,

fix a few minor things like maybe what's above you, but maybe not. If it's.

You've also got issues like the weight of a cane.

That has that kind of electronics in it. We're using that all the time.

There's some of us who are already dealing with things like carpal tunnel. We don't want to increase that percentage in the population.

And they're expensive.

You break one of those.

You're out a few hundred dollars. I break my cane.

I'm out 50 bucks.

So you really want to make sure that what you are using and what you are creating is actually going to serve that community.

And if it's a general concept that's going out for everyone, you want to make sure that you are

Getting folks who are disabled in early, so that we can help.

You think through the snags in your process.

Bruno Torquato: So we're gonna talk a little bit about some.

Recent and old developments from some famous,

software companies

and hardware companies. So one really good example of a bad hardware decision that a tech company made.

Was Microsoft, with their windows, laptops.

They're talking about replacing the very important applications, or what a lot of people call the menu, or the right click key.

Which is something that is.

Crucial to keyboard users.

They're talking about replacing that with the AI co-pilot key.

And making that a requirement for making a windows branded laptop.

That would mean that.

Anybody that's a primary keyboard user is gonna have a much rougher time using that laptop.

Then normally they would have. This is something that has decades of precedence.

And that is a really useful key. Just talking about the usability principle of

recognition over recall. You want your users to be able to look at a list of what is possible rather than force them to remember every single possibility. That's just a very basic.

Know design, heuristic.

So if you take away that key that gives them contextual options.

And tells them what they can do in any given context, depending on what they're focused on.

Now you're forcing them to remember every single keystroke rather than just hitting that key, and then saying, Oh, I can copy paste.

Select all. Now they're going to have to remember. This is just a general example. They probably know how to copy, paste, and select all.

But sometimes you don't know what fields you can do it in just right clicking. It gives you a little bit of that context.

Now you can't do that, because some marketing team decided that you need to replace that key with an AI co-pilot.

Amy Mason: Want to thank Corb for bringing that one up and on a LinkedIn article, because.

It's Banger, and it helped me to figure out, because I'll tell you what.

As someone who is a primary screen reader, user.

And keyboard user.

And has ADHD.

Remembering all 827 commands that I'm supposed to know to get through my day efficiently, ain't gonna happen.

And trying to hit the.

Function, key.

And.

The shift key, and F10 means that my fingers are all off the home row.

So you're slowing me down a lot.

And that's not even beginning to talk about if you have

mobility challenges that mean that moving your hand to the upper level is going to be more difficult.

It's just bad all the way around.

Bruno Torquato: Similarly, there's another idea from the.

Usually pretty. Okay about accessibility. Apple. This is something that's lingered for decades now, and it's kind of baffling. It's hard to explain why they haven't changed this yet.

But except for that, maybe they decided a long time ago, clearly without consulting

all of their users.

And that is that you have to explicitly turn on full keyboard access on your Mac. So.

Both in the OS,

and in the browser. So if you want to fully use your Mac with a keyboard.

You have to go into separate places in your settings and turn that on.

And well, if you can't use a keyboard, how are you even going to do that?

And so that's a really good example of like.

There's no way that they consulted.

Users with disabilities early on in that process. And so this bad design lingers and continues to be costly for them, because they have to deal with escalations and customer complaints, and they have to constantly remind people and teach people how to do this.

Very difficult to do thing.

Amy Mason: And we're stuck with designers who have occasionally realized. I think you could tab through a web page.

Bruno Torquato: Yes, I have to thank Apple for this now, when I'm training our teams internally, and I saying, Oh, you could just use your tab key to test. If what you just coded works or doesn't for a keyboard user.

I have team members. I will go. Oh, I didn't know I could do that, and then I'll go. Oh.

Right.

They probably didn't even turn it on. So I have to go and send them the article that teaches them how to turn on this very basic feature.

And that means that that also gives me a twinge of like.

Pain, because now I know that developer for the past, however long they've been working, has never done that. So everything that they built has this issue in it.

So let's thank Apple for that one.

So we also have some good case studies. You want to go into those, Amy.

Amy Mason: There are moments where something has been built.

From the ground up.

By the disability community in partnership with other.

Organizations, other inventors.

One that I am still incredibly excited by, and kind of proud of.

Is the K and FB Reader.

In, the.

Kind of.

Early 2,000 late 90 s.

As someone who's blind and wanted to read a piece of print media.

We'd have to use a staNDAlone.

Scanning.

Platform with either a computer or a truly staNDAlone solution.

That's going to be big and bulky and not leave your desk.

And that was better than not having anything, but it wasn't as good as we could have it.

And so.

The National Federation of the Blind, worked with Ray Kurzweil to develop software and come up with a hardware solution.

That allowed for the creation of the 1st generation K and FB Reader

Which literally ended up being the specialized software loaded onto a Pda.

Stuck to a breadboard with some circuitry on it, stuck to a camera.

And then there were things like, how do we make this thing.

Something that can be taught to the end user so that they can get a good focused picture of whatever they're taking.

And that development continued until.

The.

K and FB Reader mobile App was able to be created for smartphones.

And.

You know, meaningfully. Now.

That leadership has led to being a number of excellent solutions out there for.

Reading printed text as a blind person using your smartphone.

That's portable.

There's multiple options out there that are, you know, really have the.

K and FB Reader, mobile app in ability. But that's because.

That whole process was started by people.

In the community expressing a need and working with partners who can make it happen.

Likewise one of the biggest things for me in college.

I happen to, and now I'm proving my age.

Be there right at the beginning of bookshare.

When it was primarily people with print disabilities.

Actually scanning and uploading books to the service.

And it was scanned stuff from the community.

That we were then able to share to one another.

In order to access books without each of us having to.

Scan war and peace, or.

Whatever the giant anatomy textbook was.

Only one of us did it, and then we could all share that information.

And that has grown in such a way that today we have publishers who are making sure that bookshare can ingest that material.

And it's available to all sorts of folks who have print disabilities.

To get those books in the format that they can read, whether that be reading it on a portable braille display, enlarged.

Listening to it.

Choosing a specific font.

Or colors.

Set.

And that's all because the community was involved from the ground up.

Bruno Torquato: Another reason you might want to bring people in early. This is something that Sherryne always talks about, and I stole from her talk with her permission, is that there is sort of like a rule of thumb that you can think about.

About the costs of.

How just, insanely costly it becomes to not.

Research.

So if you can imagine an accessibility issue.

That.

You would normally catch at the requirements phase like we recommended. As soon as that light bulb goes off. As soon as someone comes up with a concept.

At that stage it might just be a single line item in a bulleted list.

Glancing at that and saying, no, it doesn't make a lot of sense.

Cost, very little.

And it cost very little to just highlight that one line in a bulleted list and hit the delete key.

It could maybe cost just a dollar of someone's time.

Now, if that same little idea gets kicked up to the design phase. Now you have a designer spinning their wheels.

On this sort of.

Flawed idea that.

Might take them, maybe a few minutes to come up with a design maybe a few hours. Whatever the case is.

But what would have normally cost you a dollar to just delete a line item. Now you're.

Saying, Oh, and there's been a lot of time spent designing it, the actual solution. So if you catch it, they're good. Maybe it's something that costs you only $10 to catch.

If you kick that further up the chain. Now you've got people coding that idea that your designer created that might cost maybe $100 of a developer's time, because they're spending.

You know, developers are problem solvers. So even if you give them a flawed problem, they're gonna chop at the bit to figure out the best way to do it.

And so you know, something that could have been a dollar is now a hundred.

Likewise you kick it down the road to Testers.

If you have a good ratio, you probably have a few more Qas than you do, even developers, and.

Now you've got multiple people all spinning their wheels and wasting their time on something that is fuNDAmentally flawed.

Hopefully. You know, during that testing phase, and Amy and I.

Painfully do a lot of that testing a lot of the time our colleague Becky here, can attest to that, too. We all end up catching things far too late sometimes. But yeah, it's painful. It takes a lot of time, and it wastes everyone's.

Precious precious time.

But if you can imagine, then it's something that doesn't even come to us that just goes straight into production.

Now you're also spending money on deploying it like somebody has to figure out how to put that up on a server somewhere. Someone has to figure out how to sell it to the customers.

Now you've got customers out there actually using it and figuring out that it doesn't actually work for their disabled employees. For example, right.

And then, now you have to involve support. We have tech support people handling those issues.

Then the 3 of us will have to get called into a support call to help the customer. Be reassured that we actually do have people that understand users with disabilities, and that we are working on it. And at that point you've involved.

So many people, and so many hours of so many, so much of their time.

That. What could have just been that quick delete key of the one bulleted list? Item.

Is now, you know easily 10,000 that you've been spending on this or way more. I mean, if it's in production, that's.

Amy Mason: Yeah, if it's print production, you're lucky if all you get a nasty RAM.

Unfortunately, we are all aware that right now we're in kind of a litigious.

Place when it comes to accessibility and.

Sometimes that is.

For us as a disabled user, the best tool that we have to make change.

But I don't want to have to go that route with you.

That's exhausting for me. It's exhausting for you. I don't want to be your adversary. I want to be your partner.

So.

You know, it's something that.

None of us want to dwell on.

But.

Is a reality that we have to be aware of. If things get out there.

That's the reality that can.

Happen if you're not showing.

Yeah, the humility and.

Awareness which I think takes us to our next point, doesn't it?

Bruno Torquato: Sure I think we're moving on now to. We're still planning and places to find users.

Amy Mason: Oh, yeah, I missed a whole chunk. Look at me go?

Bruno Torquato: But yeah, if you're if you're at the point where you're able to do this testing at whatever phase you're in, you're gonna need users right? So to help you plan that we have listed out here of. You know.

People with disabilities exist.

Right disabled users are out there. That's not a valid excuse that they're hard to find, or any of this.

So if you ever hear that, you're gonna be able to download this slide deck, all of these things here are links.

So the 1st thing that we absolutely have to mention on here.

Is that Knowbility, our gracious hosts.

They? They actually have a whole program around this called AccessWorks. So.

We? I don't wanna you know.

Be rude and not mention our hosts. They're very good at this, so you can reach out to them directly and find users for your.

Likewise, there's lots of consumer organizations.

Amy Mason: Yeah.

Consumer. Organizations of people with disabilities are going to be some great resources for you.

Because they are, they have the same goal you do of making sure that.

The tool is going to be accessible to their membership.

What we have on the slide, I need to tell you right now is not.

Everybody.

These are representative samples.

What we've got on the slide includes places like the National Federation of the Blind.

National Association of the Deaf.

Options themselves, advocacy, network.

ADA, the Attention, Deficit, Disorder, Association. Those are all.

Organizations that to my knowledge, with the possible exception, though I believe this is true of the National Association of the Deaf, are.

People who are of the community.

And are not.

Being spoken, for by advocates.

But are actually community members within the disability organizations. To my knowledge, NAD is also that I just don't know that organization as well as some of the others.

Bruno Torquato: Likewise we also have those.

Of.

Those agencies that directly serve communities.

Amy Mason: Lighthouse for the blind in San Francisco will set up user testing.

Centers for independent living, and in this case I just mentioned the Boston.

You may even be able to work with.

For organizations that do vocational rehab may be willing to send out.

Emails on your behalf to some of their clients.

Who may be willing to work with you.

Beyond that.

If you know the kind of tools that your users might be using like, if you're looking for screen reader users.

You can check for things like Reddit.

Forums or mailing lists.

For people who are jaws, users, or.

Voiceover users, and speaking of voiceover users. One of the biggest.

Communities out there right now, that's really an easy one. If what you're looking for is.

Visual and non-visual access to apple products is going to be the apple vis website and the community that's built around that.

And you know here's the other thing.

If you have shown me that you care about accessibility by.

Giving me information about your accessibility on your web page, or.

Through other resources.

I will likely contact you.

Like we have accessibility at UKG.

Dot org. And so if I'm having a problem, I feel more.

Confident that if I send something off to accessibility email.

Someone will know what I'm talking about.

And may be willing and able to help me.

Whereas if I send it to support@yourgreatapp.com.

I have no idea if anyone's gonna even know what a screen reader is, and I may not bother, I may just move off and not care about your greatest app.com, and go over to.

This other thing, that kind of works dot.

That's that.

Bruno Torquato: Shout out to Becky for all our accessibility at UKG emails, thank you, Becky.

Oh, yes, we have a question. Oh, where's our microphone?

Want to make sure everybody online can hear as well. Yeah.

Audience member: When it comes to user research,

Like who to be.

Involved. So everybody's different. Obviously, and different disabilities are different. I work with clients who.

They want user research done. They don't necessarily know.

Who needs to be involved in it. They just know that it's important to make sure that their website gets.

Verified by real users. So what kind of cross-section should we be, including.

In our panel of user.

A panel of users.

Amy Mason: Sounds good.

It makes sense, I would say, as wide as possible, and where things are going to.

Be challenging.

Start with the largest population that may encompass.

For instance, if you've got.

If you want to make sure that your base level is keyboard accessibility.

You have gone a long way, though not the whole way.

Toward screen, reader, accessibility.

If you have.

Looked at.

If you are looking at

Some of the mid-level vision issues you're going to catch.

A lot of people, because there's going to be a whole lot of folks who have.

Frankly poor devices where color contrast is going to be much worse.

You're going to have folks who are just a little older. And oh, that text is so small.

You know, part of the disability community doesn't even know that we have disabilities.

So.

I'd say, find the wide swaths, and find a few examples of folks who are going further.

Bruno Torquato: A good resource to just kind of uncover what some of those types of users might be is the W. 3 C. They have a series of really short videos, highlighting.

Different use cases for people with disabilities interacting with the web or with apps.

And I think it's maybe just 10 or so like.

Less than 2 min videos like the really brief videos.

That your product designers and your product managers should definitely take a glance at and see. Oh, this might be relevant to what we're building.

I forget exactly what the series of videos, perspective accessibility perspectives. That's the series. That's if if your team is just.

Very naive and hasn't really looked into disability issues.

That would be a really good starting place, the W. 3 C's perspectives. It's a really good starting point.

And then from there you could see, oh, wow! This might actually.

Impact somebody with a mobility issue. Or, oh, that's something that would definitely be a problem for a low vision user. You could just see these little perspectives and.

It might, you know.

Turn on some light bulbs in your head about who you want to research, and then.

You can refer to this list and find those people.

Oh, we have another question.

Audience member: So I've.

I've known that user testing is super important. I want to start doing it in my company.

But I haven't.

At.

How? What's the.

Way to approach these companies like, if I want to talk to the National Federation of the Blind.

How do I actually phrase what I'm looking for? And what sort of response should I expect.

Amy Mason: The organizations are going to offer different levels of support.

I will admit some of these folks. I've not even checked whether or not they would.

Pass things along.

But I can explain how it works, some for both the National Federation of the Blind and the San Francisco Lighthouse, because I worked in both of those places previously.

The NFB.

Is willing to.

Send out research proposals that are mostly pure research.

And willing to work with developers.

For a bit of a fee to help build up.

Actual testing cohorts where they would help to actually find the people.

There is, there are a number of different levels of kind of involvement. You can get.

From a lot of the consumer groups like that.

Same way with the lighthouse. You can actually have them do a lot of the facilitation of finding people.

You can actually have them be the local host for your user research, where you would bring folks into the lighthouse.

And they would help you to find the people. Bring them in, host them, and you could ask your questions and.

They can help you with things that we'll talk about in the next section, where it's. How do you kind of make this experience as pleasant for everyone as possible.

Bruno Torquato: And if you're looking for just like a turnkey solution, where.

Everything's kind of just figured out, and they'll help you get to directly what you're looking for.

I'll mention again, AccessWorks does exactly that. So Knowbility has those resources. And that's why they're here. And that's what they do. So.

They'd be very excited to help you with that. Yeah.

Amy Mason: And with some groups you're going to put out a. This is what I want. This is who I need.

And they may just be willing to.

Forward your email out to the community.

Someone like apple biz. You could post on their forums yourself as the developer and explain what's needed, and.

Seek.

Bruno Torquato: Amy mentioned a little bit of the cost of doing this, and I just want to remind you that.

Doing this stuff does cost money. But again, it's an investment that's gonna save you money in the long run. If you consider that.

Slide I showed earlier. So that brings us to a very important point, and that is.

You absolutely must.

Compensate your usability and accessibility. Testers.

Amy Mason: I have a life like all.

I'm not doing this.

For free.

This is not my gig unless you're offering to pay, in which case let's talk.

Bruno Torquato: And yeah, and if you want to get that sort of like.

Sincere feedback from someone who's very willing and excited to be working with you. You're much more likely to get good quality results if you're paying people. It doesn't take much. You don't have to spend.

Billions of dollars on this research. But just a little gesture goes a long way.

We've done usability studies where you know, we give people like a $50 gift card or something like that.

It's just a matter of trusting.

In their experiences and respecting their time, and respecting who they are as people, and just acknowledging that.

You know.

Their experiences aren't just there to inform your designs.

They're human beings, and you want to be considerate of them like you. Would any of your other users.

So that takes us to the next phase of usability studies. And that's the actual facilitation. So this is part 3.

Inclusive User Research facilitation.

Subtitle here is.

Transparency and humility make me more understanding.

Hmm.

Speaking of that.

Yes.

If you're on your accessibility journey.

You know, wherever you're at, in what phase of design like, you were just very upfront with us now. Wanted to do this, but I haven't done it yet, so you know. Be gentle with me, or what have you just being sincere like? That goes a long way.

Amy Mason: And.

Honestly, everyone here in this room and on zoom, I'd like to briefly.

Honestly applaud you.

Because you are here. You are doing the work.

You know you are wanting to learn more.

And that in itself is a good 1st step.

Following. That 1st step is, of course, the second step, which is.

Know where you are.

Work on learning where you're at.

And what the next steps are.

And make that information available to me as the end user as.

Or as the participant in your study.

So that I know.

That you were serious about this, and that you're learning.

And that you're working toward a real solution.

Roadmaps are going to make a big difference to my understanding of.

We are still having real problems in this area. We are hoping to fix it in quarter 2 of next year.

Gives me an understanding that you have an idea of how you're getting there.

Bruno Torquato: And that you're just actually making a commitment. And this isn't just like a shot in the dark that you're really gonna take this and do something with it. People respond to that.

Amy Mason: I swear I'm really serious about accessibility. Org is.

Not enough.

Bruno Torquato: Yeah, increasingly, at least in our case at UKG, we find that our customers, I mean, they're spending a lot of money on our software. So.

Increasingly when they come to us with accessibility, concerns.

They're asking for roadmaps. It's not enough for us to tell them. Oh, this doesn't work.

They're like, Okay, that's fine. We'll work with you on that.

When will it work?

And you know, just having that sincere conversation about you know where you're at is very important as a 1st step. But you're gonna want to take that farther and say.

We're planning to do this in the future.

We're planning to do that.

People want to know.

And one thing you definitely don't want to do.

When you're researching or talking to your users with disabilities, is.

Decide for them what they shouldn't care about.

Amy Mason: I get real cranky if someone tells me. Oh, you don't need to worry about that setting. It's not important.

If it's not important, why is it.

It's kind of, you know, infantilizing.

Like.

Who says it isn't important. Maybe I am the one person in the world that wants to use Markdown on your web page.

Bruno Torquato: And it's like, Oh, there's we!

Why would blind users want to use photo features? Don't be that person. Don't decide for your users what they care about. Ask them what they care about, ask what they care about.

Yeah.

So.

Transparency and humility like how you might show that is just talking like a human.

So an example. And this is all.

Jargon is very bad. You definitely want to avoid jargon when you're talking to your users.

The following word, salad is.

All terms I have actually heard coming from our company at different times, right? Like you wouldn't want to say stuff like UKG makes a, B, 2 BS, hcm, suite.

For a variety of market segments from Smb. To large enterprise.

We drive, engagement.

Right. You wouldn't want to be that person. So.

You want to turn that into English. You want to talk to your users in a way that they understand. You want to say, UKG makes online software that lets companies.

Provide a way for their employees to request time off view, pay stubs.

Sign up for benefits and other critical workplace tasks.

It also helps managers and Admins keep those things operating.

If you can avoid sounding like you're marketing your software during your testing at all costs.

You're going to get much more sincere.

And honest and useful feedback.

Amy Mason: Honestly, I've worked there for 2 years, and I'm not sure I know what all of the things in the 1st paragraph mean.

Bruno Torquato: I've worked there for 16 years, and I don't know what most of that means.

So don't be that person.

The takeaway here is that just be honest about what your software does, and talk in human words.

Research is.

Absolutely not the time to be marketing or overselling your solutions, if anything you want to understand. If anything, you want to be really honest like we said earlier about what.

What your blind spots are, what you're missing out on what you haven't done yet.

That's how you're going to get better feedback, because then the people know what to focus on.

So moving on.

Practically speaking, if you're going to be doing this user research.

About accessibility. You're gonna want to make sure that the research process itself is.

Accessible.

So right. If you're doing an interview on onsite interview.

Make sure that the space is accessible. If you're gonna bring people in make sure that there's space for wheelchair users to come into your space.

Don't have them be like, Ok, we're going to be meeting in meeting Room 103, and then they get to Meeting room 103, and they can't even fit their chair through it.

Don't be that person,

Amy Mason: Or it's up to flights of stairs in this gorgeous old brownstone, with no elevator.

Exactly.

You might benefit from variable lighting, for some of your low vision users or.

You know, and that's spatial things.

But digitally. You want to be thinking about this, too. You want to make sure that things like your

And is something that can be read electronically signed electronically.

Because neither you nor I want you to spend.

15 of our.

45 min reading the NDA to me, and then me having to try and figure out where to sign the thing.

It!

Not a good 5, and you'll never get the people if they can't use your survey. In the 1st place.

Bruno Torquato: Sometimes we have online pre surveys or screening surveys to find the users and make sure that the people that are coming in will be able to give us the feedback that we want.

If the platform that you're using to put up that survey.

Isn't accessible. Well, then, you just missed out on a really good opportunity to actually find real users. Similarly we talked about the importance of paying people.

If you end up using a digital payment platform to give people gift cards, or if you're.

You know, some whatever Disney dollars are out there like Amazon cash, or whatever you're gonna want.

The whatever platform you're using is actually accessible. You want to actually look at your research process from top to bottom and make sure that you're not leaving anyone out. Otherwise you're gonna miss out on really good feedback.

Right.

While you're testing and just trusting the idea that you don't know what you don't know. You're gonna want to always ask people things.

If there's any way that you can make it more accommodating for them. If there's anything that you might have missed.

Give people the opportunity to give you the feedback, even about the process itself, or.

You know, just a sincere question of.

Is there anything you might need to access this test? You know, you're gonna be.

A prototype in a web browser. What might you need for that?

Just ask, because there might be you don't know what you don't know. So even if you end up creating something that has some of these gaps.

Just asking people gives them the opportunity to fill in those gaps. So you might have made a mistake. And that's fine.

But if you're not asking, you just wouldn't know. So ask, always ask

Amy Mason: And remember the progress over perfection thing.

That's true for anything that we're doing ourselves.

Once again. I'm going to be much more understanding if you.

Offer. Hey? Is there anything that we didn't think about in this process that's going to make it easier for you.

You have just won my heart.

Because.

You know what.

We're not going to get it perfect.

There are.

Huge swaths of the disability community with unique needs.

And sometimes we're gonna miss something, or sometimes something that makes something more accessible for one group might make it less for another.

And it's not going to be perfect.

We understand that.

But that is really ameliorated. When you say, Hey, is there a way? We can make this better.

Bruno Torquato: That brings us right to our next point, which is.

You know.

People with disabilities are not a monolith.

There's some things you want to consider.

When you know.

There's maybe people have different histories or journeys about how they got to where they are.

And you know.

You want to ask about those things again, like we mentioned earlier, you don't want to focus on like a history or like medical details.

But you want to ask open-ended questions, to kind of arrive at how people.

And navigate the world so that you can be sensitive to it.

You want to think a little bit about this spectrum of experience.

Amy Mason: There's going to be a complete utter spectrum, just like.

Every other segment of the population. Disability is approximately 20% of the population.

Across the world. So you're going to find rich people, poor people.

People who are just learning a piece of technology, people who are.

Developers or.

Coders and can run rings around you as the researcher.

And you're going to find everything in between.

You're going to find young folks or folks who were born with their disability, folks to whom it came later.

Folks with all different skill levels.

So, remembering that we are not a monolith in any way, shape or form is going to take you far.

Bruno Torquato: And so some takeaways related to that.

As a researcher when you're actually facilitating these studies.

Try to get to know your users as people to get that sincere feedback don't just collect like usability data. But.

Get at some ethnography as well. Ask the questions around the software.

And understands sort of like how they're using it in a bigger context.

And the best way to do that is to ask open-ended questions.

So.

Like I mentioned earlier. You don't know what you don't know, so give people the opening to tell you things that you don't know.

And how that might manifest really, practically in a research study.

Just speaking from the perspective of.

Facilitating and designing those studies.

Is, don't lean just on multiple choice questions.

Or don't always lean on sort of Lichard scale. Things like a lot of researchers do.

They give you good data, but they don't tell the whole story.

It's good to collect that data. But you need to supplement that with some really more open, ended questions.

And so a lot of times I found that when we have research study results.

The things that really stand out to the rest of the team where the takeaways that they really learn from.

Tend to be.

Yes, they care a lot about the data. But most of the times.

The good quotes that you're gonna get.

Like, sometimes you get a slide deck about your research results.

Sometimes when you get those quotables that take up a full slide, and you're like, this is exactly how our users feel.

You're not gonna get that stuff. If you focus on just the raw data and the multiple choice questions you have to make room for that.

So make sure you lean on the humanity of your users to get that really good feedback that will actually change how your team thinks.

We talked a little bit about that, and that applies to.

Technology as well.

Make sure that if you're going to be testing.

Like a working prototype of something that you don't limit, the technology that it works with.

That probably means that.

You're getting ahead of yourself, and you're forcing your usability testers to do QA for you.

Right, so.

For example, if you're going to be testing a working prototype.

Don't you know? Come to Amy and say, well, you can only use JAWS version, you know, X, and you can only use that with chrome version y, and that's the only way we're going to be listening to your feedback.

Amy Mason: That's too bad. All I've got was me is a smartphone with voiceover. So now what do we do?

Bruno Torquato: Yeah, you just missed out on an opportunity.

I mean, it's okay to tell your users what you've been testing on.

But if you're saying to people, Well, this is only gonna work in this scenario. That's.

Probably not a good place to start.

And that means you probably should have been testing a little further back in the process rather than trying to test like a working prototype or a piece of code that's been made already.

Amy Mason: Well, and to be honest here, this is where the scope of what you're doing.

Generally is going to be important, because I mean, if you're an iOS app, then I understand that the only way I'm going to be able to use you is on an iPhone or an iPad.

With Voiceover.

But if you are multi-platform web.

I'm going to be awfully upset if I can't use voiceover or can't use talkback.

And have to use a specific screen, reader, on windows, and maybe even a browser. I don't use.

That's a completely different animal if everyone else can use it.

And I can only use it in one way.

There's a functionally, there's going to be a lot of problems with that.

Lot of folks don't know multiple things. They may not have be able to afford multiple devices.

And even for those of us who can.

You have lost a lot of credibility.

Bruno Torquato: For sure.

I'm going to skip a slide or 2, because I think we cover these topics already.

So yeah, this takes us to, you know.

Going back further in the design process, and instead of testing.

Only thinking of accessibility. Testing is something that you can do with working prototype.

Is.

Don't neglect to do research into design phase. You.

Can absolutely test a design for accessibility, including for blind people. You don't have to wait until you have a fully built solution that they get in front of their screen. Reader.

So how might you do that right like.

If you have a design that's already been figured out visually, there's a layout. There's some copy that some designer has written.

You can provide text-based alternatives for your users. Right.

Something as simple, as.

Taking a prototype that's like a few form fields and a submit button. For example, let's say.

And just turning that into a text document.

Says you've got a 1st name, Field, a last name, field.

A button labeled.

Send you know. What have you.

That's a really low technology, low effort way to take.

What's been created as a visual design, and to be able to put it in front of a blind user and get real feedback on.

Your wording choices, the order of the form fields.

If it actually makes sense to be collecting that type of data for the tasks that they want to complete, there is no excuse to not be doing this stuff. There's very low effort, low technology ways to get at that data.

And what that might mean is as a researcher, you might have to take on the responsibility of learning.

How to talk about this stuff so that just might.

Talking about interactions, more open-ended.

So, for example, don't be really technical with your language. Don't go to your users and say.

Oh, there's a select menu here with these options, because.

Depending on what technology they use. Maybe they call select menus.

Profound pop up buttons, combo box, combo box. There's dropdown. There's all of these words that mean the same thing, and everybody uses a different one, depending on what technology they're coming from and what history they have.

So just learn to talk about these things in a more general way.

Instead of saying, there's a select menu or a pop-up button.

Here you have a field that will allow you to select from a few choices.

This is the label.

These are the choices.

And that is a way of conveying it in a way that everyone will understand, and that you're going to be able to focus on.

The actual feedback for the design.

And this is all stuff you can do before you ever code something and find out way later down the line that you use the wrong component? Or what have you.

Right, you can focus on the wording and the choices themselves.

And that also allows you, as a researcher, to have a backup plan.

There's going to be software bugs.

Screen sharing might break down as.

As it always does.

Or your participant just might be having a bad day.

Amy, do you want to? Maybe give us an example of that, or just talk a little bit about that?

Amy Mason: Yeah. It is possible that your.

User may have come in and their computer isn't gonna work.

And they were the ones with the screen reader on it. So you may be describing this option for them.

There may be situations where you don't have a precise prototype, but you could lay something out.

I taught people years ago.

This is admittedly a little bit of a side story.

I taught students who had never really used windows before.

How the windows.

Desktop was laid out using Lego.

And it was able to give them an understanding of some of the commands they would use.

If you're using, insert F, 12.

You get the time and date insert F. 11. You get this things in the system tray.

And one of my students is like.

Well.

Does that mean? If I use insert F. 10, I get the things on the task bar, and I'm like you should try that.

And of course it worked.

So sometimes, if all you've got is a very simple layout prototype for someone to look at.

That can be made pretty easily. That'll still make a big difference.

But having a lot of those kind of open ended.

Troubleshooting problem, solving.

Things in the back of your mind, for if something's not working will let you continue, if things have otherwise gone sideways.

Or even if you don't know yet how to get there.

You can bring your users in really early and have them help you figure out. How would we get there?

One of those real high, level etiquette things.

Couple of things to keep in mind when working with someone with disabilities.

If you think that they might want assistance.

Feel free to ask.

Would you like to take my arm.

Is there a way that I can help out.

And do not get upset if they say no.

Because.

They have figured out how they're going to do it, and they're set.

I might regularly say no, I don't need to take your arm. I'd just like to walk with you.

In the same vein.

Don't touch without express permission.

This is going to be true of devices.

Doubly true of service animals and triply true of the person themselves.

You do not want to grab somebody's wheelchair and move them at all.

Without express permission from the user.

And I've known folks who have.

Dreamt of spiked padding.

For the people who are wanting to be too helpful. On the train platform.

Bruno Torquato: And that can manifest even digitally as well. Like, if you're doing a zoom research, call right.

If someone is struggling with a task.

Don't!

Be like, okay, I'm gonna take over screen recording control and just click on that for you, or something like that.

Amy Mason: It's okay to ask. It is not okay to just do. And it's not okay to just say, I'm going to do.

And if they say, Hey, yeah, please just fix that.

Go for it.

But make sure you get that permission first.st

And especially when you're dealing with like service animals.

Do your best to ignore the service. Animal.

Because if you're paying attention to it, it may be paying attention to you.

And then it's not doing its job.

Which means that it might get in trouble, and your participant might get hurt.

And none of us want any of that.

Absolutely.

So now we can continue.

Bruno Torquato: Yeah, thanks for bringing that up because we kind of flew past it. Sorry guys.

Ok, yeah, I think that does. Now, we actually have covered everything.

Mark Boyden: Okey-dokey. That was the end of their presentation. We're I'm gonna invite Bruno and Amy to join us up here.

And.

You can put questions and answers in the QA.

Box, or you can raise your hand if you'd like to ask a question.

Yourself.

And let me get.

Amy, and.

Sharron Rush: I just wanna say thanks while everybody's getting their questions lined up and.

1st of all, thanks to Amy and Bruno for coming to AccessU.

We had a blast.

I don't know if you were here when we shared your photo from the happy hour from the Unicorn. Happy hour. Great.

And great time having you there and then also for giving us permission to.

To rebroadcast and invite people to.

Learn from your experience, without having.

Have the opportunity to go to AccessU. So thank you both so much for being here.

Bruno Torquato: Absolutely.

Amy Mason: It was absolutely a pleasure.

Sharron Rush: Okay, well, the questions are coming in. So I'm gonna let Mark go ahead and.

And monitor that, and

be the Mc.

Mark Boyden: Okay, well, we've got one in the chat. Are there any accessibility concerns when it comes to scrolling down longer websites versus shorter websites.

Amy Mason: One thing you wanna definitely be aware of is infinite. Scroll is gonna cause problems for anything that is beyond that infinite point.

Absolutely.

Because.

If you infinite scroll.

The keyboard user. The screen reader user is not going to be able to get to anything beyond it.

And.

Personally.

I do not enjoy.

Having everything on a web page, especially a long page cut off.

Like.

Amazon reviews. You get the 1st 4 or 5 sentences of a review, and then you have to hit the more button.

And then you've got to go back to the.

Last one and.

Forward! Again!

Being able to expand collapse is really nice.

Points. That is my personal preference. I would recommend you. Go out and talk to lots more users about that kind of thing.

And.

The long versus short page. One thing that's going to make that much better for your users.

Is, if you have.

Good heading structure.

That is, both visually conveys and is

Significant from a.

The word is escaping me.

It's actual heading structure. It's not just.

Bigger text.

Yeah. The word has just left.

Yes.

Bruno Torquato: Yep like you want to make sure it's marked up correctly right? You wanna make sure it's coded correctly.

If you for the first

Part of this is, you definitely want to make sure that if you have long pages that they have headings to help users get through them and understand the structure and the organization of them.

And.

Thank you.

Yes, Landon said, here's semantic. That's the perfect word for that. You wanna make sure that the person is getting the semantics.

Of what you intended. That heading to mean so 1st level is, yes, you need to have headings. Second level is they need to be coded correctly, so that everybody's experiencing them the same way.

So again, there's no like hard and fast rule about like you can't or can't have long pages. It's just a matter of knowing.

How to build pages. And if you're doing user research, and you're being inclusive in that research, you're for sure going to find out what users like, and don't like about your long page or your short page, right like, if you have a page that's too short because you're using infinite scroll to constantly reveal what they're there to see. Or if you're on a really long page that's truncating everything, and they're having to also similarly interact with it too much.

If you open it up to your users, you're definitely gonna get that feedback. So there's no hard and fast rule. There's no right and wrong. It's just a matter of applying what's correct for your needs of your user and then giving them the opportunity to give you feedback about it, and keeping things open, ended.

Amy Mason: And ideally making things.

Relatively easy for the person to chunk.

So shorter paragraphs.

Bulleted lists.

Lists of links that are clear.

Things that will give people enough kind of space to separate out things, skim easily.

As long as you've got semantic paragraphs I can jump from paragraph to paragraph with my screen, reader, as easily as I can, heading to heading. So I've got a lot of.

Granularity Available.

To.

Read things, and that also makes it easier for most of your users to scam and find what they need.

So.

Mark Boyden: Just reminder. You can put up your questions in the chat, the QA. Or you can raise your hand. We'll let you ask live. Next question is from early, what are your thoughts about recruiting participants based on different experience levels?

With assistive Tech.

For example, learning to expert.

I.

Bruno Torquato: Great question.

Amy Mason: Yeah. Do you wanna go 1st for now.

Bruno Torquato: Oh, go ahead, Amy. You first

Amy Mason: I think that is fabulous because.

Your user base is probably going to be.

Across that board.

A few years ago, when I was working for the NFB. We were.

Pulled into.

Look at.

A web, page.

That.

Our team had reviewed.

And found to be really excellent.

As far as it's accessibility.

Our team are all expert users.

The people that we brought on were.

I would say.

Moder.

And even some.

Fairly beginning or learner users.

And they had a very difficult time with this page that we found to be absolutely fantastic.

And that is because, although it hit.

All the.

Major points.

It was doing things in ways that our learners and our.

Intermediate users were unfamiliar with the patterns changed.

From what they've been familiar with since.

They started using screen readers.

So where possible, get a wide swath, I mean.

If everyone that you're working with is going to be.

Of a similar.

Expected level, then.

It may make sense to narrow down.

But where possible?

A wide path is going to be best, because you'll find that the expert user has ideas that may.

Help with everyone. And that's also true for your beginning user.

And they will each provide unique context to help you understand.

Where the challenges lie.

Bruno Torquato: Yeah. And I think that it's yeah. You should, by all means.

Aware of the expertise level of your users when it comes to technology, not just their assistive technology, but technology in general.

So something that we add onto the beginning of our research studies is to ask people with technology whether that be with assistive tech or not and also how.

Proficient they are, with their assistive tech by their own. You know how, by their own perception, what they feel like. And I think that helps. You understand a lot.

And then, like we mentioned in the talk, you don't want to just collect data. You also want to give people to get.

You wanna…

create open-ended situations to collect data. So one of the ways that we do that, too, is to ask people, what are some of your most used, or some things that you do on the web. A lot.

Some tasks that you performed frequently. Some of the hobbies that you like taking part of.

And that gives you a little bit of a view into their day to day life, and how they use the web, and some of the things they do more often. So if they tell you that they're, you know, trading very like.

Fiddly and advanced with a lot of custom components. Then you it's good to know that if they're telling you that they're, you know, like emailing or reading the news. Then you know that their level of proficiency with certain.

Finer points of operating web controls might be different. But don't make too many assumptions. Make sure you're asking your users.

Like one thing. Oh, this actually brings me back to the last question. We were talking about long pages and heading structures.

Understand that, you know, advanced users might know a lot more about like what shortcuts to use. We recently did a usability study that included a lot of expert users, and they all had they immediately were using the heading shortcut key for their screen. Reader.

Granted that might be something that you'd find across a broad range of users, right, whether they're newer or more experienced. But because these people were very expert users. We just knew that right away, as soon as they opened any page. The 1st thing they did was Mesh their Hq. To get those headings.

And that's something that's gonna be important for your user base.

Understanding where they're at in terms of both their technology comfort level and their assistive tech comfort level.

Excellent question.

Mark Boyden: Another question from Matthew. Another kind of specific case. But would a news ticker widget on a website cause problems for accessibility.

Also, do you know of good resources that would have research or studies related to these accessibility? Questions.

Bruno Torquato: A news ticker. Yeah, that is.

Almost certain to be. Not a great experience for a screen reader. User. Amy, do you wanna take that one.

Amy Mason: I...

I suppose it may be possible to make a news ticker. That is.

Pleasant, but.

I think that it might be.

A better option to.

Give someone.

A method to.

Update that.

Independently, because you've not only got the challenge of it.

Either not being read by the screen reader as it changes, or interrupting what the user is doing on another part of the page as a screen. Reader, user.

But you also have the concern about.

This news teacher updating being something that

You're going to need to provide a pause.

Feature, for.

Because.

There are going to be folks for whom on a web page can be.

A problem whether that's someone with ADHD, whose attention is drawn away every few seconds.

Or.

Someone who is.

Made physically uncomfortable by.

Motion on screen.

Who might otherwise normally turn off animations.

I tend to find that automatically moving things.

Will often be coded for screen reader, interaction and keyboard interaction. So my preference is, allow me to update them.

When I'm ready to.

And you clear a lot of that.

Those potential pitfalls!

No.

Bruno Torquato: And one thing that was asked for is particular research studies that we can point to. I'm afraid I don't have anything like that on hand. But.

I can tell you that.

Any time that we've.

Tested, even.

Very carefully crafted, very.

Carefully timed.

Live messages that you know. Pop up during the users flow that aren't exactly where they are on a page.

That that has potential to go wrong or confuse people. Even in our last usability that we did with 5 expert screen reader users.

The live announcement of an error message is something that did come up.

For at least one user as creating an issue. And so.

That is something that you're gonna want to be aware of. A news ticker is problematic.

Not just because it is a live announcement, and because it's constant motion.

But because it's.

Intentionally designed to.

Take someone's attention away from what they're doing.

And that's.

On its face. Kind of a.

Unkind Interaction.

It assumes that the user, if for some, maybe for some cases it could be perfect, like if somebody is just trying to passively.

Discover new information as opposed to really.

You know, browse things manually, but in almost all cases.

People want to be in control of what they're doing with interactions. And that's whether they have a cognitive disability and or whether they're using assistive technology. You want to make sure that your user interface isn't intrusive and they're not. You're not relinquishing the control as a user.

If you do a usability study with any folks who have cognitive disabilities like ADHD or with anybody who is using a screen. Reader, you might quickly find that this feature does create some problems.

And I.

Sharron Rush: And, Matthew, if you want to. If you'd like to just send a note to.

To.

AccessWorks at Knowbility. I'm sure Ashley would be able to share some of their I mean some of their studies are not.

Shareable, because people don't want.

People don't want the world to know how.

Problematic some of their products were, but some of them that have been really, you know, had good results, and we learned a lot from.

I think she could share information with you.

So. I think, Mark, are we over time? Do we need to wrap.

I wanted.

I wanted just to say, thanks to everyone for coming big, thanks to Bruno and Amy for making.

Time once again to let us use their.

They're excellent presentation. And then to come visit us. We'd love for those of you who join to stay connected to us.

We have a newsletter you can subscribe to. All of these links are on our website at Knowbility org.

Air is our accessibility Internet rally, that we're enrolling participants right now.

The kickoff will be September 26th and you can join a team or be a judge, or be a mentor, or get a mentor in this community event that creates for nonprofit.

Organizations and artists.

AccessU where we met Amy and Bruno.

And

You're welcome to keep an eye out on the on the website for.

AccessU announcements. We'll have another.

Conference in May of 2025, at St. Edwards University.

In Austin, but also.

Also.

As a hybrid event, you can attend remotely.

And please consider donating.

Please consider giving Knowbility some consideration in your year-end giving. I know the season of everyone asking you for money is coming right up.

But our community programming relies on the generous support of advocates like you. So take a look. The donate button, as you can imagine, is very easy to find on our website.

And again stay in touch. Volunteer. There's many ways to help.

Support the mission of digital equity, including just coming to these and.

Learning about it. So thanks again.

Take the survey. We'll include this in the follow-up email, the link to this survey. Tell us what you'd like us to focus on in the future.

And again another big thanks to Amy and Bruno.

And to all of you for being here, and to Mark for doing such a good job of keeping all the tech running smoothly.

Thanks. Everyone.

Thanks.

Bruno Torquato: Thanks for having us.

Amy Mason: Thank you so much. This was wonderful.

Yay!

Yeah, it was great to see you all again, mark, are we off.