Glen Walker, TIAA, Principal Accessibility Architect

Glen talks about his early years as a software engineer and his personal interest in keyboard support. This lead him to accessibility work that included solving screen reader issues and compliance with Section 508 and WCAG. In his consulting work he continues to help other developers by sharing knowledge in a variety of ways. 

Mentioned in this episode:

Info about Accessibility at Blink

(upbeat music)

- Hello, this is Digital Accessibility.

The people behind the progress.

I'm Joe Welinske the creator and host of this series.

And as an accessibility professional myself,

I find it very interesting as to how others

found their way into this profession.

So let's meet one of those people right now

and hear about their journey.

(upbeat music)

All right, well, here we go with another interview

with an accessibility practitioner.

And today I'm really pleased

to be speaking with Glen Walker.

Hello, Glen, how are you today?

- Hey, good morning.

I'm doing well today, thanks, Joe.

- Yeah, it's good to have you here with me

for this conversation.

I'm currently in my Vashon Island home office,

which is near Blink's headquarters in Seattle, Washington.

Where are you talking to us from?

- I'm in northern Utah, up near the Idaho border.

- All right, well, yeah,

I've been through that area a number of times,

and a beautiful area.

So, well, again, thanks for being part of this

and good place always to start is just with you,

briefly letting us know,

what kind of work that you're doing now.

- All right, yeah, so I've worked for a variety

of different companies with accessibility.

And the first company I got started with

is where I got my accessibility beginnings,

and it was a software company

and we had a lot of different products.

So we're helping different teams

with a variety of different things,

working with developers, and testers, and designers,

as well as the product managers,

and working out new features.

So I've done both working at individual companies

where we do all of our accessibility work internally,

not outsourcing any of the accessibility,

but I've also worked for companies

that help other companies with accessibility.

So we worked with companies that did outsource

their accessibility work.

So working both internally, as well as with other companies

that worked with a variety,

so we'd work with financial institutions, or universities,

or retail, quite a variety of experience

because as you know accessibility spans

across all different industries,

if every company has a website, so they're gonna have

some kind of digital properties out there.

And it really doesn't matter what the focus

of the company is because accessibility is going to touch it

pretty much no matter what it is.

- Well, one of the main purposes

of having these conversations is to help those

who may not see a path for a career in accessibility

to let them know our stories

so why don't we do that with you?

If we can kinda go back in time,

you can sort of maybe pick out some of the early things

that led you on the journey that brought you here today.

And then we can kind of move our way up to

what you're doing today.

- Okay, yeah, I never imagined

that I would be doing accessibility full time,

and that it could be your whole job,

a hundred percent of your job is accessibility work.

So when I started, it was kind of for

maybe personal selfish reasons.

I'm very much a keyboard user.

So I have a software engineering background,

a computer science degree.

And so I wrote code for a long time,

very much a keyboard user when you're a software engineer.

And the company I worked for,

we had a lot of different products.

And over time we were losing some of the keyboard,

I guess, keyboard accessibility of the product itself.

We started off as a mainframe product

and then when PCs came out and this goes back of ways,

but when the mouse was coming out,

you're very much a mouse point and click type interface.

And as we focused on that,

we moved away from remembering that the keyboard

was a very integral part of interacting with the computer.

And so for me that it kind of bugged me that I could not use

the keyboard for a lot of features in our software

for me personally.

I didn't like picking up the mouse

and having to go click on things.

So I started working on code to fix keyboard issues.

So it was very much kind of a self-serving purpose.

I wanted to work better for me.

So I wanted to go fix the code, and have the keyboard work,

and this was in the early 2000s.

And I really had not heard of accessibility.

It was still pretty new.

I mean, WCAG 1.0, had only come out in 1999.

So it was only a few years after that,

that I started working on keyboard issues.

And like I said, it was really

to help things work better for me.

And I didn't really know I was doing

accessibility work at that time.

But I also had a friend who was visually impaired

that used a screen reader as well.

And he was also a software engineer.

And so he wrote code using the screen reader.

And so I got to understand

a little bit more about how a screen reader works.

We talked about some of the technical details

like of the API and how the accessibility tree,

and all these kind of internal details,

which are interesting to learn about

if you like the technical side.

But I think probably more important

was more of the user experience with how someone expects

a screen reader to work and interact with software.

What is the user experience like to navigate through pages,

and using all the different shortcut keys

that a screen reader software has.

And so I started expanding the work that I was doing

in the coding area to work on

in screen reader issues as well.

So that was really the first time I got into it.

And prior to that, it was really just coding for features,

and things like that.

And then it more and more involved with working

on accessibility related issues that our software had.

And so I spent less time writing new features and more time

writing code that would fix accessibility issues.

- Yeah, let me just jump in there

and just explore that part of your career a little bit more.

And so you had this,

already a deep understanding of code,

and identifying how that was related to accessibility.

At that point in time, looking back 20 years ago,

the web accessibility initiative was still relatively young,

like how did you pull the piece together

in knowing what was the best practices

and things at the time?

What kind resources did you find at the time

to be able to help you move forward?

- Yeah, the resources were more limited at the time,

or perhaps the resources were there,

but we didn't about them, right?

There's a lot of great companies out there today that have,

you can go on YouTube and just do a search on accessibility,

best practices, and you can find tons of stuff now.

I mean, we have conferences, and people posting podcasts,

and doing interviews like yours,

and there's all kinds of information out there now,

which is fantastic.

Back then much more limited.

So a lot of it was self-taught,

and things that we would work on,

kind of bouncing ideas off each other.

Internally, we started building up

a small group of accessibility people.

And so we would bounce ideas off each other.

We mainly had to use the,

really 'cause we're a US company,

we had to use the section 508 rule set,

which had a checklist of things to work on.

This was prior to section 508,

getting in line with WCAG 2.0 at the time.

So it had its own list of things that you would check for.

So that's what we would base it on.

I guess we had WCAG 1.0 as well.

But so it was really nice when 2.0 came out,

I think that was around 2009, 2008, 2009.

So when that came out and then it was fantastic

when section 508 was updated,

was refreshed to point to WCAG 2.0.

So now we had a common set of things that we could check for

and it was fantastic.

It made things so much more consistent,

especially when other countries started using

that same guideline.

So now when you're focusing on a checklist like WCAG

that you knew it was gonna be good for the US,

it's good for Canada, it's good for Europe,

it's good for Asia, it was fantastic at that point.

- And so then after this early period,

what was the next stage that you moved into?

- Yeah, we quickly found out that having me write code

to fix accessibility issues.

And then, well, when I was writing it initially,

it was great for the particular product I was working on,

but certainly did not scale.

You know, any company that has more than one product,

you can't have one developer work on one particular area,

the thing, and fix it all.

And so we hired a few other developers

that were interested in accessibility.

And so we expanded our team a little bit,

and we were able to cover a few more products.

And that was okay for a while too.

But again, it does not scale, especially when you have,

we had a hundred over a hundred products,

different software product.

And so, it took a while for this light bulb to go off

to say, hey, we need to really scale this better.

And really, and I'm talking from the technical standpoint,

but from a software engineering perspective,

every developer should be responsible for their own code.

Just like it is now with any kind of

functionality that you write in your code,

that a developer should be responsible for their own code

and the accessibility of their own code,

the internationalization, the localization,

all the features that go with a particular piece of code

developers should own all of that.

So we wanted to share the knowledge that we had

of writing code to be accessible with all our developers.

And so we started doing training.

I came up with a curriculum and wrote some classes,

and started teaching and sharing to other developers,

the things that I had done and the things that I had learned

so that we could spread that knowledge out to everybody.

And really that was the key,

that's when we started making a lot of progress.

And just a quick side note on that.

So, once we got things fixed,

and this was kind of a reactive approach, right?

We already had code that was written.

We wanted to see how accessible it was.

And we had to go back and fix issues.

That's not the best way to do it,

if you have the time set aside,

really you need to back up that whole process,

and work with designers and make sure that

accessibility is built in from the beginning.

And that designs are reviewed for accessibility,

they're annotated and written up so that when developers

get those designs, they understand and can code

accessibility right from the beginning.

And so it's not reactive,

you're not writing a whole bunch of code

and then figuring out, hey, is this accessible?

You're actually doing it from the beginning.

So we started training designers as well.

And then we also wanted to teach and train testers

because even though you trust the developer

to do the right thing, you wanna confirm, right,

that everything was done properly.

So you need a way to test that at the end.

And hopefully the developer is testing as well

as they're writing code,

but you need a system of checks and balances.

You wanna make sure that indeed the code was written

properly and that it works great with a braille device,

or a magnification, or a screen reader,

or all different types of assistive technology.

So the key there really was training and education,

which was a fantastic thing for me to learn.

And it's what I've taken into other companies,

no matter which company I go into,

especially ones that wanna really do a lot of the work

in house instead of hiring out.

But education is the key,

just understanding really the basics of accessibility,

and what to think about, and what to look for

as you're designing, and as you're coding,

and as you're testing.

- And then is that what led you into being more

on the consulting side of things or advisory?

- Yeah, it did.

And I did had accessibility work for a long time

at the first company I was at.

And then the more I saw, and it was great work.

As I mentioned earlier, we had a lot of different products,

and it was fantastic.

But I started seeing that there's lots of companies

out there that need help.

And so I just started kinda looking around

to see what else was out there,

and more and more accessibility companies were coming about

that really their main focus

was helping other companies with accessibility.

And I found that very fascinating because then instead of me

helping one company on a particular type of product,

I was able to branch out and work

with banks or credit card companies,

or work with universities,

or work with the big retail companies,

just to see the variety.

Well, it's kind of two sides of it.

You see the variety of the different type of work

that all these companies need,

but then you also see the commonality, right?

They all need help with headings, and tables, and lists,

and image alternate text, and user interface,

and keyboard, and screen reader.

Really it's like they're all different,

but they're all the same.

So it was really fascinating seeing that aspect.

- You mentioned, that important concept

sometimes called Shift Left,

where work is going into foundational search and design,

which then leads to a design specification

with the accessibility built in.

And that's certainly a really great way to approach that.

I work with evangelizing accessibility

to the clients of our organization.

And I still find that a lot of those conversations

are still kind of stalker or at least begin with

the remediation compliance part of it.

That's kind of where a lot of organizations

first start thinking about it.

When you were working in that advisory role,

or consulting role, what was your experience in that area?

Did you have a lot of that,

or were you able to find more progressive situations?

- I think probably one of the biggest challenges

is getting a company to care about accessibility.

Developers can be very passionate about it,

designers can be very passionate about it,

but if you don't have upper management

that really is locked into it, and interested in it,

and understanding the importance of it,

it can sometimes be hard to make some headway that way.

And you might have to do some internal evangelizing

to try to get, I guess, the motivation out there.

And there's all kinds of great reasons for accessibility.

One of my favorite though, is in the actual definition

of WCAG where it talks about,

if you just took like a Google search on WCAG 2.1

or whatever your favorite version is,

you get to the main W3.org webpage, and it talks about,

what are the web accessibility guidelines.

That it says, yes, if you follow the guidelines,

you can make your software more accessible

to a greater variety of people, which is fantastic.

But for me, the key is like the second part

of that sentence, where it says,

and it also makes your product just usable,

more usable for everybody, right?

It just makes a better product.

So that's really fantastic feature.

And that really should be the driving focus

for most companies.

There's tons of other reasons you want people

to be able to use the software and be self-sufficient.

If I'm on a doctor website,

I should be able to log in, check test results,

or schedule a meeting, a doctor's appointment,

without having to get a neighbor to come in and go,

"Hey, can you read these test results for me,

because it's not accessible with a screen reader."

And that's kinda a privacy personal issue.

So it's really a self-sufficiency thing

that you help people be able to do what they wanna do,

just like everybody else wants to do what they wanna do.

And those are really some of the driving factors there.

And of course, legal mitigation,

that comes into play, but I always try to,

I don't downplay it because it certainly

is an important issue, but I really don't want

that to be a motivating factor, right.

'Cause when you think about legal issues,

it's kind of a fear factor and fear is not a great motivator

for doing work.

Really you wanna do it for more,

maybe an altruistic type for reasonings.

- And certainly the return on investment,

there's so many. - Oh yeah.

Organizations I've talked with that just never really

realized that potentially they've been shutting out

a significant portion of their possible customer base

by not being fully accessible.

- Exactly, yeah, and I think one of the,

probably one of the misconceptions,

or one of the most common misconceptions with companies

thinking about accessibility is that it's such a huge,

I don't know if it's a huge thing to overcome,

or it's a huge topic.

And while accessibility does cover a lot of areas,

and especially if you're just getting into it,

and you're going, all right, so where's my checklist.

All right, WCAG which version we're gonna use.

All right, we'll use 2.1, we wanna be level AA.

You've got all these terms initially

that could be kinda confusing at first,

but even once you get all that down, you go,

"Man, here's a list of 50 things I need to look at

on every screen in my mobile app

or every page on my website.

That's a lot of checking I have to do, right,

to see if everything, and that's a minimal baseline.

WCAG really is just,

here's the minimum you need to do,

and hopefully we can go above and beyond that

and focus on usability in addition to accessibility.

But given all of that,

even though it might feel very large at first,

when it comes down to it,

anytime I review a website or an app,

most of the issues are pretty simple.

They're very easy to fix for the most part, I would say,

85, if you wanna put a number on it, 85, 90%

of accessibility issues are one or two line changes,

add an attribute here or there, super easy to fix.

And I think where maybe some of the time constraints come in

are that maybe it's the volume

of issues that you find, right?

Maybe you don't have any headings on your page,

Well, it's easy to fix,

change it to an H2 or an H3.

Well, but if you have a lot of heading and you have

150 websites or web pages on your thing,

well, that adds up, so.

But I think, I try to ease some of the anxiety there

to say that look, when it comes down to it,

fixing accessibility issues it's super easy,

thinking about it in advanced

as you mentioned Shift Left with the design,

making sure it's annotated in the design is super easy.

And fixing the things, as long as you have time,

if you're in a reactive mode and you have to existing code,

that really it's not too bad,

especially when you have pages that are built on templates.

So you the template and now,

it just fixed a whole bunch of other pages.

- And it's not a monolithic do all of this or nothing.

We're in such an iterative situation.

There's so many things you can do.

And any one of them help move things forward,

and improve some of the aspect for our users.

- That's an excellent point, yeah fantastic.

Yeah, you don't have to eat a whole elephant

in one bite, right?

You just do a piece meal, and really anything that you do,

let's say you only fix a dozen bugs on this age or whatever.

Well, that's great, that's much better.

And it certainly is a timeline and kind of a spectrum

on how much you can fix.

And every bit that you can do now will be fantastic.

And that anything that you fix now, you also learn that,

oh, well, I see how I should have done this

in the first place.

So now when you're writing the next page,

you're gonna do that automatically.

And so you already are a step ahead

when you're writing new pages

'cause of that past experience.

- Well, you had variety of experience in accessibility.

What are some of the things

that you're passionate about now?

Are there any particular initiatives, or techniques,

or technologies, or processes

that you're particularly excited with now,

or looking into the future?

- I like to share what I've learned.

And I think most people in the accessibility area

are the same, and it it's really a fascinating area

just because most people are in the accessibility field

because either for personal reasons,

they need some accessibility features

where they have family members, or friends,

or other people that need accessibility features.

So there's a lot of personal tie in to accessibility work.

And so really accessibility community

is just a fantastic group of people.

Everyone has great attitudes and wants to help each other.

And so I just like to share what I've learned

over these years.

There's a variety of different ways I do that.

And there's lots of online forums.

There's forms where people post questions,

and then people answer.

And even given what I've done for these many years,

I'm always learning from other people's postings,

or maybe a feature here or there,

or an attribute that I say,

oh, I've never really used that, let me go play with it.

And I learned something new

just from other people posting it.

So I focus a lot, one of the things I really enjoy,

whether it's internally at a single company,

or if I'm working with a variety of different companies,

is this education piece.

And being able to share that and help teach.

I've always thought about being a teacher in general,

like a school teacher and sharing knowledge.

And so this is kind of a little bit of a way

that I can kind of get that feeling,

but I'm sharing technical knowledge in this particular case.

And so that's what I enjoy doing.

And then I love working because of

my engineering background.

I love working with development teams.

I speak that language because I am that kind of person.

I am still an engineer.

And so I love to work with developers.

And again, going back to the easing that anxiety type thing

where if they've been asked to focus on accessibility,

they're not quite sure what it is, what is ARIA?

what are these ARIA attributes and HTML?

Is this another language or what?

And I say, "No, it's just, it's part of HTML.

It's part of what you've been doing all along."

And being able to share that.

So, yeah, my passion right now,

I think is sharing the knowledge,

whether it's through official training type classes,

or informally with online forms or slack channels

is just a great thing.

Especially working with people

who are just getting into accessibility,

'cause we wanna keep this ball rolling

with the work we've done with accessibility in the past,

and get more and more people involved with it

and excited about it.

- One of the things I like to ask people about

in this series since so many of you have such

a lot of experiences just kind of

reflect on perspective of how far we've come,

how far we still have to go.

I've been doing this work for about 20 years,

and when I kinda look back,

in some ways I think there's just been amazing

dramatic shifts assisted by technology.

And then in other ways I, if I went back 20 years,

I would've thought we would've been a little farther along

than we are today in terms of accessibility

being widely available.

So may I toss it over to you

kind of what's been your perspective in that area.

- Yeah, there certainly are.

I mean, you can look at the pros and cons

of where we are today.

I think one of the great things that WebAIM,

which is an accessibility research company,

that they've done over the past couple of years

is the WebAIM Million.

I don't know if you've heard of that,

but they analyze the top 1 million websites

that are popular I think it's around the world, globally.

And just analyzing the results there,

and see what kind of accessibility issues are,

just on the homepages of these most popular things,

and most popular companies.

And it's kind of, it's disheartening to see how many issues

are still out there, even though, as you mentioned,

we've been doing this for 20 years or so.

But it's also great to see, I think, from a job perspective,

there are companies out there always posting all the time

that they want accessibility,

maybe not accessibility experts

because it takes time to learn all this stuff,

but somebody who is interested and has a desire

to learn about accessibility that it's there,

the job aspect out there is fantastic, right?

I mean, you can go to A11yjobs.com,

and there's always job postings out there.

You can go to the Slack channel.

Well, the Slack workspace has a jobs channel

for accessibility and there's always postings there as well.

And really if you were just interested

in any particular company,

you could go to their job career site and list the job page

and do a search for the term accessibility and the title.

And you can almost always find something.

So in that respect, it's kind of a pro, right?

Because there are some great jobs out there.

That also means that companies are listening

and our interested in accessibility

and so much so that they wanna hire someone

who's full-time job is accessibility.

So in that respect, it's great,

the word is getting out there,

and companies are interested in it.

But as I mentioned before, where we are now,

why we aren't further ahead than we are,

it takes time, but I try not to look at

maybe not how far along we are,

or how depressing it might be that we aren't further along,

but looking at how much progress we have made,

and how it's getting more and more popular out there now.

- Well, I think it's great that you brought up that

your positive optimistic reality

that there are so many opportunities for people

to decide to come into this area.

So I'm glad you brought that up,

and mention all those resources.

And I'll put those into the show notes

because it certainly is a great time

to be looking for opportunities

to be a professional in this area.

- Yeah, it really is.

And there's a new group of,

a new generation of accessibility people coming in.

And one of the things I wish we had more of was

in university curriculum, right?

As part of the computer science degree program,

or as part of a digital design degree program

is to have a class, a full semester class,

at least on accessibility.

I think that would be fantastic.

'cause it really is something that all developers

that take a computer science degree should understand about,

and all designers because of the Shift Left,

and designers have a lot of impact on what developers do,

that everyone understands all things.

So it would be great if we could work more with universities

in getting that built into to curriculum.

- Yeah, I agree that,

and I teach at the university of Washington

and that's something that's continuing to improve there.

But yeah, I agree that's gonna be in a really important area

moving into the future.

Well, Glen, I want to thank you for taking the time

to tell us about your journey

and share some of your insights and experiences.

And I look forward to meeting up with you at a event

in person at some point.

- Yeah, it'll be great to get back into it.

It was unfortunate when COVID came out,

and it was right around CSUN was just about to roll out.

And so people kept dropping out of that back in 2020.

So it's great to see conferences.

Well, I actually, the positive side of that right,

was so much online meetups and conferences were now online

and people could participate more economically, right?

You could just maybe pay your conference fee,

but you don't have to, you don't have to travel.

And this pointed out issues in various video,

like we're using Zoom here.

What are the accessibility features of Zoom?

Can I navigate through all the buttons and things

with a screen reader, and with my keyboard.

And it was a fantastic thing,

if you think of the silver lining of COVID

that because of all the online work that had to be done,

there was a lot of accessibility gaps

in online productivity tools.

And now those things were quickly fixed

because we were very focused

we had to have things that worked.

And so yeah, it will be great to be back in person.

It's great to have face to face interactions with everybody,

but we certainly did learn a lot from the pandemic,

and using all kinds of digital online tools.

- Well, again, thanks for participating in this,

and see you soon.