Prior the Digitally Accessible Finance & Insurance Event on July 19. Digia11y Accessible Founder Juan Olarte talks with Samuel Tesfamichael, Principal Accessibility Specialist at Sun Life.
Samuel is a seasoned web accessibility and inclusive design professional with diverse industry experience. He is passionate about applying and maintaining accessibility guidelines across business units and portfolios.
He has been with Sun Life since April 2015, when he joined as UI Design & Technical Lead role. He later transitioned to a Principal Accessibility Specialist. Samuel has designations through the International Association of Accessibility Professionals (IAAP) as a Web Accessibility Specialist (WAS) and Accessible Documents Specialist (ADS).
Accessibility 101:
with Samuel Tesfamichael of Sun Life
Introduction
[Juan:] Today we have Samuel Tesfamichael and he’s going to talk to us about accessibility, Samuel, thank you so much for being part of the podcast. And can you please tell us a bit more about you and how you started in accessibility?
[Samuel:] Yeah, so I have been, I’ve worked, I would say for the last, uh, God almost, uh, 18, 20 years now, uh, was in web design and development. So, I started as web designer, uh, uh, then web developer. I also worked as a sort of UX designer, but I came into accessibility because I think somebody sort of commented on a design that I did. Uh, I remember having like, uh, an H1 one in my design followed by H3, which, uh, looks good visually, uh, and had, uh, things like, like that all over. And somebody said, this is not actually great, ah, accessibility practice. You may wanna go in order from H1 to H2. So, I don’t really understand why then, uh, then I start digging into it and I start, I learn about, screen readers, uh, and, uh, start slowly start learning about other assistive, technologies. So that’s really where, uh, I realized, you know, uh, I, I, I was not really doing, uh, things, in an inclusive way and from the right way, just, I was really focused on visual uh, look and feel. So that’s really how I kind of, uh, went into accessibility and it just went from there.
[Juan:] Yeah, thanks. You know what I like about it? Is that you started from the design and development perspective. A lot of the times it’s in my experience, it’s great to, to be there because you know how to change or how to, um, um, do development and, and be able to go right away and making the changes into your website. That’s, that’s actually really important.
What are some of the things you wish you knew when you first started with Accessibility?
[Juan:] What are some of the things you wish you knew when you first started with it?
[Samuel:] I would say, I wish I knew, in particular about screen readers way early, because, screen readers do open, you know, your, your mind into how you should code. So, you focusing mostly on best practice, which comes free with HTML, right? Using semantic HTML, just using it the way it was created to, to be. So, I wish I knew more about screen readers because a lot of my years, I would say in the, in the beginning was spent really on specializing in CSS. And with CSS, you could do a lot of, creative things, but at the same time, you could really, you know, create a lot of problems where, you know, something looks, on top, but, technical it’s actually on the bottom and things like that. So, I wish I knew about screen readers, a lot earlier.
[Juan:] Yes, you know what? I agree, being able to have, or exposure to assisted technologies, early on is, is, is great, and, and I encourage everybody to really go out there and learn about screen readers, whether it’s going to be for iOS, mobile devices, desktop, or even the Mac operating systems. But also, I encourage, I encourage for people to learn more about other assisted technologies, screen magnifications speech recognition. So that’s a great point. being able to, to start utilizing assisted technologies early on.
What was a big accessibility problem you faced and how did you fix it?
[Juan:] Now, can you tell us a bit about a, of a big accessibility problem that you faced and how did you fix it?
[Samuel:] Yeah, so I think, some of the challenge that I faced is, for example, when you are dynamically showing an update, you know, we use aria-live to announce, but I have been into a project where, changing some things were actually updating multiple things, above, you know, the, the, the focus line. So that, that was a bit of a problem. and, what I learned, well, I, I know this is different from screen reader to screen reader, but if you actually do use, uh, uh, polite instan-, instead of assertive like ARIA, it goes to polite, it does still read it in order. it would read one and it would go to the other one, but when you do, assertive, I think it just reads, I can’t even remember just the first one or the second one. So that was one challenge for sure. Another one was something about footnote where, you have, multiple links that go to the same footnote. And, uh, so when you do back, you know, do you go back to the first one second one, or do you just go on the top? So that was another issue, but I think I later found out technically you could do it using the JavaScript, basically almost acts as a browser back button when, you click on one, it would go to the footnote you were before.
[Juan:] Yeah, that’s an interesting, that’s an interesting, issue. I know I’ve worked on a lot of publications where you have to provide accessibility feedback for users, and you’re correct, utilizing the Aria-live region is going to be one of them. And switching from polite to assertive gives a big difference because when it’s polite, it lets the assistive technology actually, see or complete the user interaction and then it’s going to-to talk about that. And another thing to consider is probably using the aria-atomic as well, which is in combination with the, with the, aria-polite and aria-assertive in terms of the live region. Thank you so much. That’s actually a very good, a very, a very good, issue to have and to talk about.
Adding accessibility to a project or early on within development life cycle
[Juan:] So what are some of the important things you do when, ensuring that accessibility gets added to a project or early on within development life cycle? Do you have a process you usually follow?
[Samuel:] Yeah, At this point, actually we’re pretty, where I work in my company, we’re pretty accessibility aware. So we really consider accessibility, early on, you know, sometimes even starting from a wire frame, where, you can sort of notice, certain things. So, I would say we start from a design phase and a lot of the time you can actually catch things, just from the design. I mean, colour is one of them, but if you have a lot of learn more, click here, type of stuff, or even you look at a layout and you see the desktop version and you see the mobile, if it’s not really stacking properly in the way it should, but there’s a different presentation for mobile. That could cause a problem sometimes because screen readers just care about what’s in the dome, right? So, I would say we’re, we’re good, at catching things ahead of time now, because we are involved early on, and our, UX is, pretty open for feedback. So, we, we kind of go back and forth and I would say catch most of it during design phase.
[Juan:] Yes, I like that. I think design phase is very important, especially when it comes to wire frames, annotations, accessibility at that point is really preventive and, and it’s going to help everybody, completely agree with you.
Engaging different teams within the organization about accessibility
[Juan:] Now, you talk about the design phase, but also you go from design to development to testing. How do you engage different teams within the organization or, or even stakeholders, to ensure accessibility taken under consideration? Do you have a specific type of a process or technique or training? I would like to, to, to hear more about that.
[Samuel:] Yeah, so in terms of developers, developers are really part of the discussion in design. So, because eventually they are going, the one who, who are gonna code it. They do catch, a lot of these things early and, you know, the stakeholders usually, they want to ensure, obviously they want to finish a budget on time, and, I mean, project on budget and was on time. But at the same time if you let them know, doing it this way will actually cause a problem for, let’s say, assistive technologies users and stuff. They’re pretty, uh, aware, uh, of that. So they are willing, to, uh, given, you know, it’s, it’s not always that easy sometimes, you know, uh, you would hear something like, oh, maybe we could, uh, fix that on the second phase. Let’s just finish it, things like that. But over time, I would say we have come to a point where accessibility is really, really a priority. And, uh, it’s really a matter of when you’re saying this is not a great idea. I just give a way forward, you know, give a suggestion. This may not be great, but let’s do it this way. And they would, uh, they would definitely entertain it and go with it. I guess, if you’re just rejecting something without really giving an option, that’s a problem. But other than that, I’m finding, uh, you know, uh, we, we work pretty well overall and they’re receptive.
[Juan:] Yeah, that’s, that’s great to hear. And I guess that also speaks a lot about the culture of the organization, being able to, to, uh, engage with different teams and, and different stakeholders.
Thoughts on Overlays
[Juan:] Now, uh, I want to maybe take a little bit, uh, another way. Um, I’m wondering, do you know, or have you experienced overlays and if so, what is your experience and your thoughts on overlay tools?
[Samuel:] So, where I work, we never have them, but I do know what they are, I have seen them in websites. I have actually tried them, without mentioning any websites. Uh, I think they are, like a temporary solution. They’re not in my, in my opinion, they should not be a solution, but, some people do them for different reasons. So, they could be a temporary solution because you’re not actually fixing the code. Uh, you know, this is, uh, insert one line of JavaScript and it presents certain way to users at the same time it doesn’t work very well with users’ own assist tech-technology. A lot of this overlays come with their own readers or other things. So, uh, to me, I definitely would stay away from, from that. They, they, it’s not a solution because eventually if you remove that one line of script or two line of script, it’s back to where it was. So it does, it doesn’t really solve, the issue. and it gives specially companies, organizations a false sense of security that they are accessible. So for the people who know, you know, they, they can reject it or they can temporarily use it as a solution. But for companies, I think when it is sold as a service, I think we need to be very clear that it’s actually not fixing the code and it should not be, used long term, but my personal opinion is avoid them all together.
[Juan:] Ya, thank you so much for that. I agree sometimes there may be an intern solution and organizations just have to be clear in terms of what they can do with it and what it can actually do.
Conclusion
[Juan:] Now, our last questions before we, we finish this great interview is, for people who just start in, in the accessibility journey, do you have any advice? what are some of the things that you would like to provide as an advice?
[Samuel:] Yeah, I would say definitely, as I said earlier, I wish I knew about screen readers early on. So I think, get a screen reader NVDA is a great one for free really, understand, try to navigate, a webpage of your favourite site or you know, sites usually frequent, just with a screen reader And then you’ll realize, if a site is really coded very well it’s easy, and it’s inclusive for everybody, but if it’s not, it’s such a, a problem for somebody to just get, little information, right? So I would say start with screen reader, but once you understand how it works, then I think you really will love, you know, using semantic HTML because by default, HTML is accessible. We just run into problems when we try sometimes to get fancy, you know and also depend so much maybe on Aria. So I would say it’s good to know Aria what they, what Aria does it’s capability, but you know, know your HTML, know the semantic nature and the accessibility features. but definitely start with a screen reader. It will open your view completely.
[Juan:] Thank you, Samuel. I really appreciate you being part of accessibility 101. Thank you for being, a speaker in our event. And again, it’s been a pleasure.
[Samuel:] Yeah, it’s a pleasure, Thank you.