Stephanie Walter tells us that designers should provide a roadmap to their design for the developer, but in many projects, there just isn’t time to do that.
Thanks to Twilio for sponsoring the transcript for this episode.
Make sure you have a look at:
- Their blog: https://www.twilio.com/blog
- Their channel on Youtube: https://www.youtube.com/twilio
- Diversity event tickets: https://go.twilio.com/margaret/
Transcript
Nic: Welcome to the Accessibility Rules podcast. This is episode 82. I’m Nic Steenhout and I talk with people involved in one way or another with web accessibility. If you’re interested in accessibility, hey, this show’s for you.
To get today’s show notes or transcript head out to https://a11yrules.com. Thanks to Twilio for sponsoring the transcript for this episode. Twilio connect the world with the leading platform for voice, SMS, and video at Twilio.com.
This week I’m speaking to Stephanie Walter. Stephanie, thanks for joining me for this conversation about web accessibility.
Stephanie: Hi, thanks for having me.
Nic: I like to let guests introduce themselves. So, in a brief introduction who is Stephanie Walter?
Stephanie: Oh. So I’m a user experience designer currently based in Luxembourg. I’m super interested in a lot of things, especially mobile design and also a little bit of accessibility. Otherwise, I like to travel a lot and give conferences all over the world. I teach at the University. I do a lot of things. I also have a blog with a few articles on it. And, yeah. That’s pretty much it.
Nic: You’re juggling a lot of different things.
Stephanie: Yeah.
Nic: So, let’s get warmed up, and, to get started tell me something most people would not know about yourself.
Stephanie: A few people might know it now because I put this into a conference description but I actually designed a crane monitoring application. Which is kind of super weird. And, also I really really enjoy not design. Like a lot of designers want to do this really nice cute things. I kind of enjoy designing supercomplex forms, tables, things like that. I had once to redesign a form that was automatically generated using a SVG file and it was a form with seven levels so you could have box into box into box into box. You could have until seven different levels of reusable and editable components in this form. It’s for customs and taxations form. But, yeah. I had a lot of fun doing that.
Nic: You know, that sounds like a great challenge.
Stephanie: Yeah
Nic: It’s one of the things I talk with people a lot and they tell me, “Hey, Nic. Accessibility is so difficult. It’s such a chore” but you seem like you’re actually tackling it like as I tell people, you like a challenge. Look at it as a challenge.
Stephanie: True
Nic: What was the biggest challenge in making that form work from an accessibility perspective?
Stephanie: Ah, I only designed it so I didn’t do the HTML and CSS. But already from…
Nic: Okay
Stephanie: …from an accessibility perspective, for instance, like error messages, they were in red and that was pretty much it so the difference between an error message and information message because they also like this for taxations. So, we have a lot of different information messages and the only thing that was differentiating those two messages was the color. So between blue and red which is already an issue…
Nic: Oh yeah
Stephanie: So even that kind of thing. It was a quick fix, we just added a little icon, a different one for the real errors and another one for information.
Nic: Right
Stephanie: But that was like, big improvements already, and like, information architecture. So, this is more about visual information but basically one of the biggest issues at the beginning is when you have seven different levels you weren’t quite sure in which level you were. So, really having a visual with also like the developer did a lot of things to have an information architecture that let people understand on what level they are. It was quite the challenge. I ended up printing the form on A4 sheets and went with a ruler and tried to put those lines on top of the form to understand indentation and tried to make sure the current information was put together. It was crazy. I don’t know how long the form was but… yeah. It was fun.
Nic: Excellent. So the primary purpose of our chat today is web accessibility and every person I speak to seems to have a slightly different definition. How would you define web accessibility?
Stephanie: Making sure it works for as many users as possible with different disabilities. Also, different context. Like, make sure that you build a website that isn’t going to be an issue for some of your users. So, like, try to not put more fences than there is already in some technologies. Don’t make it worse, because, I think there was this fucking webpage website that was basically a webpage without any CSS, without any Javascript. Just text. And they were like, “yeah this is responsible, usable and accessible “ I’m not… I don’t 100% agree with the usable because since you didn’t have a container the number of characters were line dependent on your browser size. But, still, the idea was to say to people, yeah look, by default whatever you put in the browser is kind of responsive, accessible and we with our technology break that. It is easy to do because it was just so many, like, text. If you start playing around with forms and all of those supercomplex content, of course, it gets a little bit more messy. But, the idea behind was quite interesting, saying okay, we have the tool to build something that works and isn’t broken but sometimes we add some extra layer of whatever technology and we break it. Usually not on purpose.
Nic: Yeah, usually not on purpose but often out of ignorance I think
Stephanie: Yeah. But that’s the thing. I’m not a frontend developer but I know about HTML like Semantic HTML because of my background, and sometimes I have to fight just to have a label linked to the input. Into the forms. Like, I’m not talking about fancy ARIA stuff, things refreshing on the pages, complex repeatables, form elements… I just want to have a label linked to the input and because… yeah, this is important for accessibility but it also adds usability to be able to actually be able to touch the long label instead of sometimes those little checkboxes or things like that. And even that I’m sometimes confronted with developers who are like “What, how do you do that?” Sure, let me show you.
Nic: Yeah
Stephanie: So even that is complicated sometimes.
Nic: This is an interesting topic. One of the things I am always curious about is what is a designers responsibility in making sure a developer codes an accessible page? Because often… often developers get a design and it’s a little bit like a photo of a good looking cake but there’s no real recipe on how to make the cake and when you compare what the photo was to what the final design is, what the final… not design, the final page looks like, it’s often very different. So, where does designer responsibilities start and end with that?
Stephanie: I think it depends on what your designer does, because as I said, due to my background I have knowledge in HTML and CSS so a little bit about accessibility and code. I know a lot of designers that don’t do any HTML and CSS but still, I think as a designer you’re supposed to give some elements to your developers to help them. For instance, were you designing a form you can be like… I don’t like to say lazy so I’m going to put a big warning in here. I don’t think designers who only design one input sheet are lazy. Sometimes they don’t know and sometimes they don’t have the time to do more which usually, for instance, when designing forms, the input they have a style for the default. I have a style for the focus, I have the style for the input when it’s filled, it’s the same for a button. I have a style for hover, I have a style for focus and things like that. So, I think this should be the designer’s responsibility to provide those kinds of components in different states to the developers. The issue is in many projects they just don’t have the time to do that. So, that’s why I’m not saying it’s like… most of the time I don’t think they’re lazy. Sometimes you just forget. Okay the developer is going to take care of this kind of effects because it’s happening in the browser. And, whether you’re designing in Sketch or Adobe XE or Photoshop. All of those tools are still static so what you design, as what you said, a pretty picture but you don’t have all the interactions. So, I think the first thing to do as a designer is if you have time and if you have a budget to do that… prepare those interactions so the developer actually also thinks about doing that. Sometimes they just forget about the focus or the hover over buttons or form fields and things like that. And, then make sure it got implemented. So, ask to see the final result and test it into the browser, like, not only visually testing checking if it looks …
Nic: Stephanie, how did you become aware of the importance of web accessibility?
Stephanie: I think I was… it was a conference in France that’s like… yeah, there’s a few conferences in France and you have ParisWeb that had a huge track on its accessibility. So, this was kind of the first time I heard about it a little bit. We spoke about it while learning HTML at University but it wasn’t a big focus on accessibility, it was a focus on semantics which results in accessible code which is great but it wasn’t like, ‘do semantic for accessibility’ it was ‘do semantic to pass the W3 validation test’. Because that was the times when you just have these W3 validated little yellow stickers at the bottom of your website. So, yeah, I kind of learned about it at conferences. Then I was a little bit more interested and when I came back… I was working in Germany, and then I came back to work in France for a small web agency and they had an accessibility expert when I arrived. Then they hired another one so we had nine people in the team with two accessibility experts, which is kind of amazing compared to the number of accessibility experts you see in other companies. So, yeah, one of the main focus of this small company in France was actually to introduce accessible code and also acessible designs.
Nic: Right. So, has your view of accessibility changed over time since you first started becoming aware of it to where you’re at today? Are there things that you used to think that have changed or… yeah.
Stephanie: I feel like when I started I think performance was still in the definition of accessibility at that time. Something like making a website accessible to people whatever they were using, and I think performance was a criteria as well. People with slow bandwidth and things like that. So I think they removed it or am I mistaken?
Nic: I don’t think performance was ever part of the…
Stephanie: Okay
Nic: … standards in North America. It might’ve been in Europe so I’m less familiar with that aspect.
Stephanie: Yeah, maybe. And, yeah I’ve seen more and more countries embracing accessibility today. Like, you have the Microsoft inclusive design principles and things like that. And, also, the thing like they added a few things in new norms which are more like in what they would call cognitive issues. So, I feel like at the beginning it was a little more restrictive and they kind of widened the accessibility spectrum.
Nic: Yeah
Stephanie: Because there’s something about animation, motion sensor, motion sickness… things like that into the new criteria.
Nic: As a designer how do you leverage the new WCAG success criteria that target cognitive impairments? How does that help you or make your life more difficult?
Stephanie: For the moment… the thing is, in Luxembourg, there wasn’t… no not only in Luxembourg but in Europe there was a law that was trying to influence the WCAG criteria but it was the 2.0 so, to be honest at the moment I would be super glad if we were even able to inform the first version, like 2.0. That would be amazing. So, that’s still, like… yeah… this is kind of a big issue for us as well. Like…
Nic: So, you’re saying that in Luxembourg you have to… you have to adhere to version 1.0 of WCAG, not the…
Stephanie: No, 2.0
Nic: 2.0. Okay.
Stephanie: It’s a little bit strange because, you know, in France, they have the RGAA which is kind of based on the WCAG but a little bit different. And in Luxembourg, it’s supposed to be the WCAG 2.0 but they have this thing called Renow which is guidelines not only for accessibility theres also guidelines for user experience. Thing’s like that. But, yeah, it’s basically the same criteria so when you’re doing a website for an institution, something like that, you are supposed to follow the rules but usually, I’m like the elephant in the room. I arrive, I’m, like, “yeah you have bad accessibility “ and people are like “what are you talking about?” “well, you know, you’re an institution, this is a public website so…” the strange part is usually I’m the one kind of bringing the news about all of the legal aspects of that. I’m like, “Hey, hi, I’m a designer” I’m not supposed to be the one, like, you’re supposed to know about that. You have a public website or something.
Nic: Yeah
Stephanie: But, yeah, it also kind of brings a lot of issues. For instance, one of our clients, we needed… they needed to use, or they wanted to use a framework and they ended up in a meeting where they asked me, “Yeah can we use prime MG?” and I was like, I’m not even sure what the project is about and you’re asking me what framework you can use? So I got the frontend developer and the accessibility expert of the team and he told them that, yeah, you could use whatever framework you want, you know, because it’s angular so in the end it’s HTML and CSS. We just have to make this component accessible but the question was, how much work is it going to be to just make this component accessible?
Nic: Yeah
Stephanie: So it’s always kind of complicated and a huge debate when you’re the one asking about accessibility while you’re not really the kind of expert in the team. You’re just a designer raising a few questions. Usually, people look at each other like, “What? What is she talking about?”
Nic: So, yeah. Other than some surprise what are your clients’ typical response when you say, “Hey, you have to build something that’s going to be accessible”? Do they typically go, “Oh, alright we’ll make it happen.” Or are they kind of negative and are they pushing back about it?
Stephanie: It really depends on the client. Usually, they are kind of okay as long as it won’t impact the budget. That’s usually not a given. But the thing is with the European website, for instance, they have created this framework and if you use it the right way… like you use those colors the way they’re supposed to be combined and their components… you have this whole framework that has already accessible components. So, usually when I… what I do now is like, “Are you going to use this European framework for the redesign of your website?” and they’re like, “Oh, yeah, we’re going to use it” and I’m like, “Okay, sure” so that should be fine. But for some of the clients, I think as long as nobodies complaining. But, sometimes people do complain, for instance, we have a website with all the laws of Luxembourg and we were asked to do an accessibility audit review of this website because some blind users complained. So, some blind users went to the government and were like, “Hey, this is the website with the law of the country and we can’t access those.
Nic: Right
Stephanie: And we’re supposed to… I don’t know about Luxembourg but in some other countries, it’s like, thou shall not… they shall know about the laws or something like that. So as soon as a law is published you’re kind of supposed to know about it but if you can’t access those laws… so, even those websites are not like perfectly accessible. It was fine, there were a few issues with the search. That was the main big problem but frankly was complicated because, again, those are … the websites, they’re doing it themselves. The content of the law is generated using a PDF that gets parsed and then it tries to generate whatever HTML it can.
Nic: Yeah.
Stephanie: So, basically there’s no title hierarchy for instance. So, it’s just like a big blob of HTML soup.
Nic: Yeah
Stephanie: .. and totally understand that a screenreader goes crazy with that kind of soup. So, yeah. That’s what it is. That’s the complicated parts. This is the thing we told them we can help you with whatever’s around the law but if you’re generating this with your kind of HTML and CSS soup we can’t do a lot about it. So, you need to change that as well.
Nic: Yeah. That makes sense…
Stephanie: … you need to change that as well. That’s the complicated… But I checked in different countries. France it’s the same soup and I think that… I felt that the one in Quebec was going to be a little bit better but it’s still like super, super ugly HTML.
Nic: Yeah, it’s very tricky. I think any country that decides to draw their own standards instead of rely on the W3C’s, WCAG guidelines is going to end up having issues. It’s a… I think it’s unavoidable.
Stephanie: Oh but no, in Luxembourg there is like WCAG is just like this Renow thing is just a nice way to tell them they have to follow the WCAG.
Nic: Okay
Stephanie: You know, more kind of digest way.
Nic: Right
Stephanie: And also they put, as I said, usability performances. Renow is kind of basic guidelines for websites in Luxembourg.
Nic: Stephanie, what’s your greatest achievement in terms of web accessibility?
Stephanie: Can I brag?
Nic: Yes, of course! That’s the whole purpose of the question. For you to brag. Go for it.
Stephanie: Using yellow in might portfolio
Nic: Okay…
Stephanie: No, I’m kidding but it’s quite a challenge to use yellow on a design and orange so I’m super happy to. I found a way to use yellow and it’s not like, not readable and still accessible and it works pretty well. So… guess that was one of the challenges. I was like, yeah I really want to use yellow but it’s going to be a nightmare for accessibility purposes.
Nic: So, describe to us how… how did you make it work?
Stephanie: I have this big place where I have like yellow background so I use a really dark color on top of that. Like, the buttons are pretty much okay. I have an issue with the linking at the beginning where I was just underlining those with yellow but it didn’t have sufficient contrast. So, what I ended up doing is like, having a double, kind of, line. Like the CSS underline of the link plus the yellow.
Nic: Oh yeah?
Stephanie: Which is no… and also I have some fun. I really wanted to keep this kind of strange effect where the underline goes a little bit further than the actual text, so I played around with a CSS line to make that happen.
That really was quite a… yeah, it was kind of my challenge. I was like, yeah, I really want a yellow and purple website but that’s going to be a nightmare to make that accessible. So, I… yeah, I used a color with small little touches at different places.
Nic: That sounds really interesting. We are going to have to provide our listeners to… with the link to the site so they can actually have a look and see what it translates to.
Stephanie, let’s finish this first conversation with a simple question. What’s your favorite word?
Stephanie: In English it’s ‘moist’.
Nic: Moist. Why?
Stephanie: I think it’s super funny.
Nic: Okay
Stephanie: I just don’t know why. It’s just like… “moist”, “moist”, “moist”… yeah.
Nic: Okay, thank you.
Stephanie: It doesn’t have any meaning. I just like how it sounds.
Nic: You like the way it sounds. That’s wonderful.
Alright, Stephanie Walter, thank you for being a guest on the show this week and I look forward to continue talking with you next week.
Stephanie: Thank you
Nic: Thanks for listening. Quick reminder, the transcript for this and all other shows are available on the show’s website at https://a11yrules.com Big shoutout to my sponsors and my patrons. Without your support, I couldn’t not continue to do the show. Do visit patreon.com/steenhout if you want to support the accessibility rules podcast. Thank you.