Episode 7: Why Web Accessibility Matters

rethink.fm

In this episode, I’m chatting with Rian Rietveld. She is a Web Accessibility expert and leads the WordPress Accessibility Team. She is my first international guest, and lives in the Netherlands.

This is a topic I’m passionate about. I finally get to ask Rian all those questions that have been floating around in my head about Web Accessibility. Rian explains why it’s important, and what we need to know. A complete transcript of this podcast is now available.

Meet Rian Rietveld

Rian is a WordPress engineer.

She has been developing for the web for over 17 years and focuses on web accessibility and usability.

She works at Human Made and leads the WordPress Accessibility Team to improve WordPress core.

Show Notes

Rian’s Website: http://www.rianrietveld.com
Rian’s Twitter link: Rian Rietveld

Helpful Links:

• Accessible Ready Themes from WordPress.org
• W3C Accessibility Standards
• The A11Y Project – A community-driven effort to make web accessibility easier.
• WordPress Accessibility Team – Useful Accessibility Tools and Plugins
• wA11y – The Web Accessibility Toolbox
• WP Accessibility Plugin
• tota11y – an accessibility visualization toolkit
• Accessible Ready Themes from WordPress.org
• Utility Pro Accessible Genesis Theme by Carrie Dils

Rian also mentioned a Reader View available on most desktop browsers and mobile devices. I found the latest version of Safari has it. It is the first icon with horizontal lines in the location (URL) bar. I found an extension for Chrome called Reader View that offers that too.

---

Complete Transcript:

Open PDF version of this transcript

Jackie:	Hey everybody. This is Jackie D’Elia with Rethink.fm, the forward thinking podcast about web design and front end development in WordPress. Each episode I’ll be talking with fellow designers and developers who are exploring new ways to approach and solve the challenges we face as our industry evolves. I’ve got questions so let’s get started. Welcome to Episode 7 of Rethink.fm with Rian Rietveld. We’ll be talking about Web Accessibility today, what you need to know and why it is important. Before we get started I just like to remind you, if you’re enjoying these episodes of Rethink.fm please head over to iTunes and leave a review. It really does help and I thank you very much for doing that. Let’s get started.
Jackie:	Hi Rian.
Rian:	Hi.
Jackie:	Thank you very much for joining me and I’m so happy that you’re going to be talking about accessibility with us and things that you’ve been up to. For those who don’t know you, would you tell us a little bit about yourself?
Rian:	At the moment I’m a WordPress engineer and I work for Human Made. 25% of my time goes to WordPress Core. I improve with a team, the accessibility of WordPress Core for people with a disability or use the internet in another way most people do. I’m also part of Genesis Community, so I know you off that.
	I live in the Netherlands with my son and my husband. I love to work in my garden. Anything else you need to know?
Jackie:	Oh, we’re both gardeners. We both love gardening. Yes. I do too.
Rian:	Well, thank you for having me.
Jackie:	Thank you. First question for you is how did you get started with WordPress? Then how did that roll into your accessibility focus?
Rian:	I’ve been developing websites for 16, 17 years now. I started with just plain HTML pages and then I tried out some CMS’s like PhpNuke, this was a big disaster. Then I wrote my own little CMS but slowly that was too small, I needed the proper CMS with all the features.
	I compared some CMS’s like Joomla and Drupal and WordPress and I can’t remember why I chose WordPress, actually. I think it was the separation between the themes, actually the work you do and WordPress itself so it was easily updatable and I loved the community. There was a large community, you could ask anything on the forum and there were people helping you. It was a very, very friendly community and it works out of the box so it was very easy to make something for clients very easy with all the features in it. That’s why I stayed.
Jackie:	How did you start using Genesis? What was your reason for choosing that as a framework to work on? Do you still use that now?
Rian:	That I use Genesis is Remkus De Vries fault. I heard him talk at WordCamp Netherlands about the Genesis framework and I thought, “Well, that’s good.” I always used Twenty Ten (theme), way back, as a framework for what I built on. He told me so in the talk he gave about the features of Genesis, about the hooks and the filters, and how you can move stuff around. I tried that and I really, really liked that. So, thank you, Remkus.
Jackie:	Genesis is wonderful.
Rian:	Also the community’s awesome.
Jackie:	I love the Genesis community. It’s wonderful. If you’re not in the Genesis Slack channel, you should definitely go and request access to that. It’s a great place to hang out with Genesis folks. How did you get started with accessibility and that focus? How did you become an expert in accessibility for WordPress?
Rian:	In 2010, the Dutch government decided government websites needed to be accessible. I thought, “Well, that’s a huge market. Let’s try out if I can learn that.” I followed the course with the Dutch accessibility foundation, how to go to accessible, I implemented it in my work. I didn’t get any work from the Dutch government, but I did get work from Dutch foundations who needed an accessible website, like the Dutch Eye Association. I discovered WordPress was not accessible at all, so I had to do a lot of fixing. I thought maybe it’s easier if I fix WordPress itself, so that’s why I joined the accessibility team.
Jackie:	For those who have heard the term web accessibility, but may not understand what it encompasses, can you go over some of the issues that web accessibility is trying to address?
Rian:	I think everybody has some issue. Some people, when you get older, you can see contrast less. You really can’t see a gray text on a gray background. It looks very posh, but for many people just can’t read it. If you have an iPad and you hold it in the sun and the contrast isn’t good enough, you can’t read it. Everybody has benefit from it. Just not only color contrast, but people who can’t use mouse. If you’ve broken your arm and you want to use a website with keyword only, if the website’s built accessible you can access everything with only a keyboard. Then there’s, of course, the people who are blind. They get the website read out so it has to be decently built to actually work that.
	There are also people who can see and who can speak, but can’t use their arms. They navigate a website through speech. They can say “press that button” or they can give commands to their computer to navigate a website. There’s all kinds of different ways people can navigate. There’s also people with limited sight who can see only, for example, through a straw. They see so much like you were seeing through a straw. If you have everything on the website wide apart, they have to search on the website for “where is it? Where is the submit button?”
	If the controls you are using for a form, for example, are close together, it’s much more easier for them. There are a few examples. It’s not only for blind people, but it’s for a different kind of people. There’s, of course, people who are deaf. You’ve got to subtitle your video because otherwise they can’t hear it, they can’t understand it. Just all kinds of aspects.
Jackie:	What does the WordPress accessibility team do now? What are you working on in the future for WordPress?
Rian:	Mainly working on the admin, because the front end, that’s themes, and that’s the theme developer. We have no control about that. In the admin, we can make the admin so accessible possible so that content managers with a disability, everyone can use as good as possible. For the theme repository, we developed a label called Accessibility Ready. If you want to submit a theme to the WordPress repository and you have accessibility ready tech with it, it gets reviewed. If the site is accessible enough … That’s themes. That’s what we do for themes.
Jackie:	How about plugins? What’s the state of the plugin market with accessibility?
Rian:	Do you know how many plugins there are?
Jackie:	Not off hand.
Rian:	Totally not doable to actually review that. It’s undoable. What we want to do is educate developers so we give talks at WordCamps and on Contributor’s Day we’ve got workshops. We want to publish a handbook. At WordPress.org/accessibility, there’s a link to the handbook. We are writing that to give developers as much resources as we can. Fixing plugins is just undoable, of reviewing that. If someone gives us a lot of money, maybe, but I don’t think that will happen. There are plugin and theme reviewers who are asking the accessibility team, “Can you do a review?” That’s paid work, so that’s okay. There are plugin developers who hire accessibility experts, like Yoast hired Andrea Fercia. He is also on the accessibility team. He is busy making the plugins from Yoast accessible.
Jackie:	It sounds like the education is the key here in getting developers and designers who are working on plugins and themes, how to make theirs accessible. Another thing is getting the accessibility inside the admin panel. What’s the state of that now? How would you rate where that is?
Rian:	At the moment, it’s pretty good. People with screen reader, who are blind, can use it pretty good if they get proper training. One thing that’s really not good at the moment is the media. Media is very difficult for screen reader users and for keyboard-only users. That’s really a project to start, but that will be a huge task. We’ve not started that yet, but the rest is pretty good and we’re getting better and better. I’m very optimistic about that, but we’ve done a lot of work already, and we’ve got the support of the release leads. Now we’ve got Helen (Helen Hou-Sandi), and she is really into accessibility and everything we do now is supported by her, so that’s excellent. The last few release leads were also very supportive.
Jackie:	What do you think the state is for the WordPress community overall in how we’re approaching accessibility? I see a lot of sites that I’ll go to that are not as accessible as they should be. I’ve even got some of mine that I’m constantly trying to do improvements on. What do you think the overall state is now, and how do you see that improving in the future?
Rian:	The last two years, something changed. Before that, nobody actually cared. Now, suddenly people are eager to learn and they also … Once you get involved … I’m very, very hopeful, but what you said before, we have to educate the developers. I think they also have to educate themselves. All the knowledge I have is through studying. Everybody can do that if I can do it.
Jackie:	What are your thoughts on how we should approach accessibility discussions with our clients? Especially when they’re concerned about cost and thinking accessibility might add to the cost of their project?
Rian:	It’s the same as responsive. You don’t add to your quotation. “Oh, I will make it responsive, that will cost you so much extra.” You just make it responsive, it just comes natural now. Same for accessibility, you build it accessible. You don’t even have to tell them. You can explain somethings to them when they add content, like adding structure and add alternative text to an image, and then I say, “It’s very good for Google.”
Jackie:	Speaking of Google, do you think that the future might be where there’ll be penalties for websites that are not accessible as they’re doing with-
Rian:	That will be the day!
Jackie:	They did that with responsive themes. If your site is mobile friendly, you get better search rankings for that. Do you think, at some point, it may be accessibility as another factor in your ranking?
Rian:	I hope so, because then there will be a lot of money for accessibility if Google decides to rank accessible websites better. If you build accessible, Google is deaf and blind. It immediately benefits Google. If your heading structure is logical, Google can make better sense of your site. If you have decent HTML, Google can read your site better. If you have old content in your page instead of in images, Google can read the content. I think accessibility benefits SEO.
Jackie:	I agree with you on that, for sure. If you’re just starting off, you’re a developer/designer, and the work that you had been currently doing or in the past had been doing for clients, didn’t involve a lot of accessibility focus. You’re not as familiar with how you should approach it and how you should start, what are some five things you can do for your own website or a client website to help it be more accessible?
Rian:	First of all, build it decent HTML5. Don’t use a DIV if you actually mean a BUTTON. Build this and run it through the W3C validator. Get all the errors out. All the HTML should be semantically. If you have a block quote, use a block quote. If you have a button, use a button. If you have a link, use an A, an anchor. Use a header, use a aside, use a main, use a footer. Make a decent structure of your site and tell a story with your HTML.
Jackie:	Does WordPress do that out of the box?
Rian:	Twenty Sixteen theme does that. It is decent, a very decent thing. Very accessible. 2015, too. I hope 2017 also. Decent HTML, that’s your foundation. Every screen reader reads decent HTML. That’s first. Then, make everything keyboard accessible. You can try it yourself, how to use it, how to navigate with a keyboard. Can you access all functionality by keyboard? If you use, for example, your hamburger menu, a DIV to open and close, a DIV gets no focus if you tap with a keyboard. If you are using only keyboards, you can’t open and close a menu. Use a button because that button can focus. I wrote something down. Having structure is also important. People who use a screen reader can navigate with it. It’s very easy if you only have one H1. That H1 represents what the page is about. The rest, you divide into H2, and after H2 comes in H3. Built a story with it. Built the paragraphs with it with the headings. Just don’t use a heading just because you want something bold. A heading should represent the content that’s below it. It’s the same. It’s storytelling HTML. You tell a story about content.
	Another tip is meaningful links. Click here. That’s a very terrible link name. Also, Read more. Why is this? If you have a screen reader, you can call a list of links to quickly navigate through a page to another page, but if all the links are click here and read more, you don’t know where to. You have to read the full page to actually know where you go to. If you have meaningful links, that will save screen reader users a lot of time. You also have the links that are empty, that are nothing at all, like only a Font Awesome icon. Then you have to add (screen reader) text with it. Another one is color contrast. Use sufficient contrast so that everybody can read your site. Was that five?
Jackie:	I think so. Are there any tools that you can use for checking contrast?
Rian:	Yeah, Google contrast ratio checker and there are dozens.
Jackie:	I’ll post some links in the show notes here for folks if they want to check that out.
Rian:	There are also drop tools, you can check the background and the foreground. If you go to WordPress.org/accessibility, then there’s a link, “useful tools” and there’s a list of all kinds of tools you can use, and also contrast checkers.
Jackie:	My next question is about font sizes. I know you and I maybe have chatted about that in the past in the Slack channel. I noticed when the last Genesis sample theme came out, they’re using pixels and rems for the font sizes. I noticed some themes are just using pixels. I realized that support earlier, in older browsers, for pixels, didn’t scale very well on responsive themes. I think a lot of folks were using ems at the time. Can you just talk about the difference between the three and, going forward, what should we be focusing on?
Rian:	Em is I think the favorable one. That’s just very, easily scalable. This responsive stuff, having a font size in em, it’s depending on its parents. “Who’s your daddy?” You can’t be always sure how large it is. If you use rem, that’s fixed. You actually know this is always that size. It’s the same as pixels. There’s a direct relationship between rem and pixels. Em is relative from its parent. Em is supported by all browsers, all versions from way back. That’s really backward compatible, and rem isn’t. Browsers are getting smarter and smarter. I think it’s the same as “Do you still support Internet Explorer 6 or 7?” Everybody has a rule. I don’t support below that IE version. What you see nowadays, if you look at the browser, you can have a few … I don’t know the english word for that. In Safari n the right in the URL, if you click on that, you get text and you can adjust the size and you can adjust the contrast. It’s also on mobile phones. Do you know how it’s called in English?
Jackie:	I do not know what that’s called. (Reader View)
Rian:	If you have an iPhone in Safari, then you have, on well-written sites, three lines on the left, and if you press that you get only text. I think they have it in desktop already now.
Jackie:	I’ll find the information on that and post that in the show notes as well. That’s interesting. I haven’t seen that.
Rian:	Most browsers can enlarge very well.
Jackie:	If I’m going to be doing a Genesis project now, should I be looking … I’m using SaaS, so when I do my compiling I’m using postcss, and there’s a package that will add the rems on for you. If you’re used to using pixels for your font sizes, it’ll go ahead and put the rems in and use the pixel as the fallback. That seems like that’s the way the sample theme in Genesis is now. I think I had asked you previously, and you said, “If you don’t need to have that strict support, then pixels is fine for most browsers.”
Rian:	It depends on your audience. If you have an audience with very old browsers and you think they need to enlarge, then you use both. If you have a very modern audience, well … There’s one snag, if you want to have your site validated for the WCAG rules, then you have to have scalable font sizes. It fails if it doesn’t have rem or em, if you want to validate for WCAG rules because then it has to be scalable.
Jackie:	In that case, you would have to be using rems or ems, and ems would definitely have more backward compatibility for older browsers.
Rian:	Yeah. Depends on what you choose from. I think most modern browsers can enlarge easy with pixels. I don’t know if anyone’s going to shoot me now.
Jackie:	I’ve got a question. I’ve used that Tota11y plugin, it’s like a Chrome plugin. You can put it in and then it will show you the contrast ratios and the headings and the errors that you’ve got on your site. One thing I’ve noticed on the Genesis themes is, and maybe it’s on all the WordPress themes too, the skip link has an H2 tag. It comes first. That usually gives you a warning that you shouldn’t have an H2 before an H1, which would be your logo or your page title. Is that something you can just ignore?
Rian:	There are different rules for accessibility. For WCAG, you have A, that’s basic, AA, that’s globally used, and there’s AAA. That’s really strict. Having an H1 not as first heading is AAA. That’s very, very strict. Worldwide, AA is used and AA doesn’t care. If you really want to be very strict you can change that, but it’s not necessary.
Jackie:	It’s definitely not something if a client goes and checks their website using that tool.
Rian:	Maybe you should add your quotation to build a website to AA, and WordPress itself is aiming for AA. That’s the global standard.
Jackie:	Is it necessary to have an H2 for the skip link? Does it even need a heading tag? Could it use something else? I guess that might be a reason for the screen readers?
Rian:	Screen readers can recall a list of links, but also a list of headings. If they see skip links, they can jump quickly to the skip links because they recognize them from the headers. It’s more convenient than a requirement.
Jackie:	The other thing I wanted to chat about was images, and I know you mentioned it earlier. Making sure that you have good ALT tags for your images. I think when I’m building out a site, I don’t have any problems doing that for the images I’m adding. Educating clients about using ALT tags for their images is something that I try to do and make sure. I get a lot of questions about what’s an appropriate ALT tag for an image. I wrote a post not too long ago, maybe last year, on my blog about … There’s lots of different reasons. If the image is adding context to it, then how you would want to define the text that’s in there, and describing the photo if it’s a photograph, can you give us some guidance on an overview of that?
Rian:	There are two different kinds of ALT text. You have alt text with a description of the image in it, and you have empty alt text. You can leave the alt text empty. Don’t remove ALT tag, but make leave it empty. That’s for decorative images. Then they’re not read out by screen reader. They aren’t bothered with it. If you think this adds something to the context, you can add a short description. You don’t have to say, “This is an image of … ” because it’s already read out as “Image” and then the alt text. It’s “a beautiful flower” or whatever. A portrait of (name). You can use both in the content. With a description, keep it short, or without, then it’s totally skipped.
	If you have a decorative image in your theme, use it in the CSS as a background image.
Jackie:	What about captions on an image? Would that be duplicate read out for a screen reader if you added text to the ALT tag.
Rian:	It’s duplicate.
Jackie:	Sometimes I’ve seen where the caption has a longer description about what the image is and tells a little bit of the story of it, and then what would you be putting in the ALT tag?
Rian:	A very short something.
Jackie:	Something very short.
Rian:	Or nothing.
Jackie:	Or nothing at all, and the screen reader would skip the image and then read the caption out.
Rian:	I think so.
Jackie:	That makes a lot of sense. We talked about contrast ratios also. I think that’s something designers struggle with a lot. I know I have in the past, too. You’ve got something that’s pleasing, you like the way that it looks, and then you go and check it and it doesn’t comply.
Rian:	Especially when you use orange. Orange is always a problem. Getting contrast right for orange and white. It looks very pretty, but it’s hard to get the contrast right.
Jackie:	If you’re close enough to the right ratio, are you okay? If your project is not required to be compliant, or should you really try to get your contrast ratios to show up all green in that Tota11y plugin?
Rian:	The contrast ratio 4.5. It’s up to you.
Jackie:	Especially, I guess if you’re reading text. That seems to be where it’s really, really important. Text on top of a background. You want to make sure that that text has enough contrast to be read.
Rian:	If the text is larger, the contrast ratio can be less. For headings, for examples, that’s a contrast ratio of 3.1, I think. For small text, 4.5.
Jackie:	How about icons? Icons seem to be a source of a lot of discussion. Font Awesome had icons and they were using an tag. I saw later on, I think it was you that had written a post. I had read that about putting in some screen reader text in there to describe that icon so that it would be read out. Using a tag instead of the tag. Do you still recommend doing that?
Rian:	Yeah, because the tag has semantic meaning. It means text in a different voice. Span has no meaning, like div. Div and span have no semantic meaning. You can use them for that. I think you should always have the text visible, to the icon, because a lot of people just don’t know, for example, what the hamburger menu means. We are all very clever. We’re designing for the web. The people who are using it, they are not. They have to guess a lot. “What’s this icon for?” The hamburger menu, I think, is the most misunderstood menu of the web. A lot of people just don’t know that that’s a menu, so add just a text menu to it, and then your site will become much more usable.
Jackie:	I think the hamburger menu on mobile seems to be more understood, because some of the mobile devices themselves use it to represent menus. I agree. I’ve been putting the word “menu” and the hamburger menu next to each other so you can actually see the word there as well, instead of just … I know a lot of clients like to have decorative icons for actually links that go to pages, or things like that. Sometimes those designs may not call for having some text underneath of it. In that case, you’re left with an alt, if it’s an image. Say you’re using a PNG or an SVG for your icon. If it’s an image, you put an ALT tag in there to describe what that is. That’s one way. If you’re using a FontAwesome icon then you would recommend using a span tag and then doing screen reader text for that?
Rian:	Yeah, the screen reader text is text that is hidden from sight but read out by screen reader.
Jackie:	If you hover on it, and you want a title to show up on the hover, like a tool tip, so that a sighted person can understand what that icon’s representing, how would you put that in?
Rian:	There are attributes you can add to an element called ARIA. You have got one ARIA attribute that’s called ARIA label. In ARIA label you can say what a link of an icon is about. You can style that. You can style the attribute so when you hover over an element than it shows up. There are various ways to do that.
Jackie:	I like that idea. That sounds very good. Just hover over it and it would automatically show up.
Rian:	It’s a pity the screen readers make such a mess of the title attribute, because it’s such an elegant way. There’s already there, but screen readers don’t do that well.
Jackie:	No, and it seems like everybody’s removing the title tags for most of the links now anyway, because it’s repeating the same information again out in the screen reader.
Rian:	It gets read twice. It’s really a lot of noise.
Jackie:	Talking about the icons again, do you have any opinion on whether or not using CSS transitions and transforms can help with accessibility for … Say you’re hovering over an icon and you don’t want to change the color, or just changing the color alone may not be visually enough for somebody to visually detect that they’re hovering over it, that maybe doing an enlarge of an icon, or turning it a little bit, or doing some animation with it, can that aid in it, or would that be something you wouldn’t recommend?
Rian:	Why not? I think if it looks pretty, why not? There’s one thing. If you change it on hover, it also changes the focus. If you change something when you go over it with the mouse, it’s very easy if you copy the style also to focus because people who use keyboard have to have the change too.
Jackie:	Typically when you do a focus, you might get a little box around your icon then, some dotted lines that show up around your icon.
Rian:	Yeah, which you can add any style you want to it, of course.
Jackie:	You could do the animation on that as well. When you’re keyboarding over those icons, you could actually have them enlarge a little bit, and turn a little bit, just like you would hovering over it with a mouse.
Rian:	I think so. When you have a link, for example, it must stand out as a link just so that people aren’t guessing, “Okay, is it a link? If I hover over it … Okay, that’s a link.” It must stand out in the text as a link. Any transitions or styles, if you make them pretty, why not?
Jackie:	Thank you for that advice. I’ll definitely be taking advantage of that. We’re just coming up almost to the end of our time, but I wanted to just get in one more topic real quick, was forms. That seems to be a big source of issues for a lot of people. There’s many form builders out there, there’s many form plugins. You’re not sure if they’re accessible. Do you have any favorites that you’re using now, or some tips for us to make sure we are building accessible forms?
Rian:	The most accessible at the moment that I know is Contact Form 7. The author is working very hard to make it as accessible as possible. There is a plugin from Joe Dolsen, who makes the initial form. If you start a form in Contact Form 7, it’s without labels. It’s only input fields. With the plugin, it gives a good example on how you start accessible. I would recommend that. I also wrote a blog post about it, how to make contact forms accessible. The author is really working very hard on that. He’s really a very nice guy. I know they are doing work on Gravity Forms to improve the accessibility. There’s also a plugin who improves Gravity Forms. I didn’t investigate ho very well that is, but there’s work being done, I think. I also recommend Contact Form 7. I have it on the Dutch Eye Association, and that gets checked every year for access for rank at AA, and it passes every year with the forms in it. I think that’s good.
Jackie:	Contact Form 7 is it. Most of the popular ones that we all hear about in our community, seems like there’s more challenges with those for accessibility. I know there are some that even only work with JavaScript. If you have JavaScript disabled, nothing shows up on the page at all. I’m doing some investigating before I want to say any specific product names, but I’m doing some testing on those just to see if there’s any fall backs for that.
Rian:	I think it’s more a problem for people who are using Opera Mini, and a large part of the third world is using Opera Mini. If there’s a fall back for that, I don’t know.
Jackie:	That would be something to check your forms out on that to see if they’re working properly.
Rian:	Yeah.
Jackie:	Well, Rian, it has been incredible talking to you. I hope everybody has learned a little bit more about accessibility and adding it into their daily workflow. If they want to follow-up with you and chat more or learn more about what you’re doing, how can they reach you?
Rian:	On Twitter. (Laugh) You spell it.
Jackie:	I’ll put it in the show notes. Thank you very much. I really appreciate you being here today, and look forward to talking to you again.
Rian:	Thank you.
Jackie:	I hope everybody else has a great week. Thanks, Rian.
Rian:	Bye-bye, thank you.