COGA, Scoring, and Process: What’s coming in WCAG 2.2 and Silver

Transcript

Sheri Byrne-Haber: I am here today to talk about “The future of accessibility.”

There’s a number of initiatives underway, and if you’re not tracking what the W3C is doing, this will kind of be a summary of what’s coming, plus or minus over the next two years.Some of the things I can talk about in fairly concrete terms. Some of the things are a little bit still up in the air, so I’ll try to point out at each step what stuff is done versus what stuff is still a little bit in flux.

Recently, I transitioned, a role at VMware. I went from being the Accessibility Manager for the program that I started up into being an Accessibility Architect. And so what that means is I get to focus on accessibility innovation and outreach, and that freed up a lot of time for me to work on a number of different accessibility initiatives.

So I belong to the ITIC group, where they’re the people who decide what the VPAT templates look like. I’m on the IAAP Global Leadership Council.I work in two different segments of W3C. One segment is the overall Silver program, which we’ll talk about in more detail in a few minutes, and the other is the Maturity Modeling Subcommittee.So part of Silver will contain a maturity model where you can figure out where the organization is doing well at maturity and where you need a little bit of work. And that program is set to scale from one-person consulting companies, all the way up through companies the size of VMware, and universities and government organizations.So with that introduction, I’m going to go ahead and get started.

So first, I’m going to assume that you guys don’t really know anything about W3C, and I’m going to take us through an accessibility timeline. It’s like how did we get here, where we are today and what isit that we know is pending. I’m going to talk a little bit about general WordPress accessibility advice. I’ll talk about the guidelines in the WCAG that are going to be updated in the next release, and also the new guidelines that are pending.

So first of all, the timeline. So accessibility started before 2006 but it really hit the mapon 2006. I can’t believe it’s been 14 years since the Target lawsuit. So the Target lawsuits was the first lawsuit in the United States, we are a very litigious country, that went all the way to a written ruling. And the written ruling was yes, websites have to be accessible.

And coincidently, that’s also around the time where can 1.0 came on. At the end of 2008, WCAG 2.0 came out.So what happened around the same time as WCAG 2.0? iPhones. So there were no mobile specific guidelines in WCAG 2.0 because mobile and native apps really weren’t a thing when WCAG 2.0 was released.So then we had kind of a long gap where of about ten years.

And then in the summer of 2018, WCAG 2.1 was released,so this was plus or minus two years ago.

And also Section 508 merged with WCAG 2.0, which was the older version. So Section 508 is the public sector purchasing rules in the United States. And in the United States, the definition of the public sector is anybody who’s spending federal money either directly or indirectly. So that includes things like, you know, government organizations, the military, health and human services, the TSCA. But it also includes people who get money from the feds.

So it’s anybody who’s spending Medicaid and Medicare money, which is hospitals. It’s anybody that’s in any type of publicly supported schools, all the way from preschool head start programs, all the way up through public graduate programs in universities. It’s all the states. It’s all the municipalities.It’s the civil service, the post office, the court systems, the police systems.

Everything I just identified there, comes under Section 508. And there rules in 508 that say you can’t buy anything that’s not compliant with WCAG 2.0. Now, unfortunately, for the 16 years that 508 had existed up until that point, because it had its own standard previously that also said things had to be accessible,but it was being measured in a different way, 508 was more known for people not following the rules,then following the rules.

So, in 2019, September 23rd, the EU had its stop sell web soft deadline. And what that meant is any software that was released after this date that was going to be public facing had to be accessible or the EU governments wouldn’t buy it. So again, the United States is very litigious so what happened? People who have disabilities started suing companies who weren’t complying with WCAG 2.0. And we’ve had 4600 lawsuits in the last two years.

Looking at the 2020 trends, it might’ve dropped a little bit, but only because the courthouses were closed for three months for nonemergency cases in most states. And so, the trends now are back up to where they were in 2018 and 2019. 2020 will be a little bit lower overall but only because of COVID, not because filing lawsuits is slowing down for accessibility.

So initially, it was the public that was suing for over accessibility. “I can’t buy my Beyonce goods.”
“I can’t buy my NBA tickets. Now, what’s happening is employees are suing employers for disability discrimination over inaccessibility.”

I couldn’t get this job. I couldn’t get this transfer because you choose to buy inaccessible software.”
So putting the pressure on companies not only to build accessible software but to buy accessible software. Okay, we just passed the stop sell firm deadline for the E.U. in 2020. That was September 23rd, which was, you know, a little over a week and a half ago. You are here, so that’s where we are with respect to this accessibility timeline. In 2021, in Canada, AODA, in particular, A-O-D-A, 2.0 AA, will kick in January 1st. Up until now, Canada in Ontario has only been required to meet WCAG 2.0, and the native app piece of the European Union legislation will be taking effect.

And then, finally, the AG 3.0 Project Silver. And let me explain what that means. So WCAG accessibility guidelines W-C-A-G, it’s a bit of a misnomer. The W.C. is for web content, but the guidelines are for any software. It’s for native app software whether it runs on mobile or on a desktop platform. It’s for HTML-based software that uses the web. It’s also for documentation.

So originally, they decided to drop the W.C. from WCAG and just call it AG: Accessibility Guidelines. For those of you who remember your high school chemistry, AG IS the periodic symbol for silver. And so that’s how this ended up being called Project Silver.

Another thing that’s coming out in 2022 is the European Accessibility Act. That will be the first extension, in terms of adoption by the E.U. member states, where each E.U. member state will had to have locally adopted pending European Accessibility Act, and then the European Accessibility Act will be final in 2025. And that will include websites regardless of whether or not they’re public-facing, so it will be all websites, and it also includes products that have hardware components of them.

So the European Accessibility Act is much broader than EN301549, which had these stop sell deadlines in 2019 and 2020, and then for the web, and then the apps kicking in, in 2021. So this is a “how did we get here” and “where is it that we know that we’re going.”

So what’s going to be part of all of these W3C guidelines? Well, first of all, I want to talk a little bit about WordPress accessibility, and this may have already been discussed in previous conversations, so I won’t take too long to go through it. But they are a bunch of accessible templates out there. There are accessible plugins out there. If you take an accessible template and you put an inaccessible plugin in it, you’ve just broke accessibility. So the entire experience needs to be accessible. It’s not just enough for the template to be accessible.

Things that are commonly used with WordPress that are mostly accessible, but you have to make sure that you implement them in an accessible manner are Microsoft and Google forms, SurveyMonkey, MailChimp, Qualtrics, and Survey Gizmo. Lots, and lots and lots of survey systems, especially survey systems that are designed to go with design tools, those tend to be inaccessible. It’s the standalone survey systems that occasionally are accessible.

But you need to check these things because if you implement, for example, Hotjar, on an inaccessible–sorry. You implement Hotjar on top of an accessible system; Hotjar is inaccessible, that’s going to cause problems for your disabled users.

Okay, so, as I said, make sure that your entire experience is accessible. That includes the surveys, the communications, you want to have an accessibility email address where people can send in comments or complaints. You should have an accessibility statement on your site. You need to make sure that your customer support can handle people who are contacting you using assistive technology. That usually means you want to have two modes of customer support, one that’s voice-based; one that’s not voice-based.

At a minimum, if you’re a teeny, tiny company, email is going to be the most accessible customer support.My deaf daughter will rarely pick up the phone and call people through a relay service because it’s just too slow and aggravating for her.

You want to make sure your social media posts are accessible.That means use captioning and described audio for your– any videos that you’re posting when necessary, but don’t use an accessible WordPress template and then partner it with inaccessible vendors because you can’t call yourself accessible anymore at that point.

So the first thing that’s coming, and it’s already somewhat released, is COGA.And COGA stands for Cognitive Accessibility. So before I get too far into COGA, I’m going to talk about the W3C process overall for doing updates.

First, they charter a task force. And so, there is a COGA Task Force. Every Task Force has a charter. That means it has a very specific focus list of things that the Task Force is allowed to research and published guidelines are.

Then the second thing they do, is they solicit volunteers.W3C is largely a volunteer-driven organization. There are some permanent employees, but I would say probably about three quarters, if not more of every Task Force is volunteers.

You can join at any time, and that is a hint. If you go to the W3C website, you can set yourself up an account and you can request to volunteer for particular a Task Force. Then there is this, what seems to be sometimes endless series of meetings that includes drafting new guidelines, and in the end, there is a vote amongst the Task Force to decide whether or not the guidelines should be presented to the public.

That is a system that was set up because the groups, the Task Force are large enough that you’re not going to be able to make all the people happy all the time. And everybody has their own perspective. I am participating as a person who works for a super large public sector–not–sorry, not public sector. Super large private sector tech company.

Other people who belong to the Task Force work for small consultant companies, large consulting companies, accessibility specific companies. We have people who belong–who work for banks, who work for Google, who work for Amazon. So there’s a lot of different voices on the Task Force and not everybody is going to be happy with the end result all the time, which is why there’s a vote.

Okay, so we repeat number three as many times as necessary to get something that we feel is good enough to release to the public. So right now, if you want to join the Silver Task Force, you have to commit at least six hours a week of time to the meeting that are happening and the outside drafting homework that you may be assigned, after you feel that your skills and your integration is at a good enough level that you can participate in some of that week.

Okay, then what happens is something called the First Public Working Draft is released.Sometimes, additional information is released as well. For example, there is a note that’s currently been published about the challenges of applying the W3C guidelines to SAS,to cloud-based software that don’t have monolithic releases, that are releasing little, teeny tiny updates all the time.So some things are notes but some things are–there’s definitely always a First Public Working Draft.

Then there’s a comment period where people can submit in the public, non-volunteers can submit comments and we loop back to number three. So we take the comments, we have more meetings, we decide whether or not we’re going to update what we published in the First Public Working Draft and then we vote again. Once that is done, then we have the Second Public Working Draft.So this will be an updated version that contains comments integrated that were decided to be included.You know, again, a comment period, obtaining comments from the public. Loop back to number three.So you can see lots, and lots and lots of meetings. And then the standard becomes final.

So this is what we’re working on right now with WCAG 2.2, Silver and COGA. All three of those are in the middle of these processes. And then after the standard becomes final, it’s outside of W3C’s control, but it does get incorporated into laws, lawsuits and settlements. It took four months from the time that WCAG 2.1 was released until we saw it in the first settlement agreement, so that was really, really fast.

Most of the time you’ll see that companies that are entering into settlement agreements get about 18 months, from the time of the settlement agreement was executed until they have to be compliant with what’s in the settlement agreement. But it can be shorter because the settlements are purely within the control of the company that got sued and the people who sued them, the plaintiffs and the defendants, effectively.

Okay, so looking at the Cognitive Accessibility Task Force, it’s a joint Task Force between the AccessiblePlatform Architectures Group and the Silver Group, the Web content accessibility guidelines.We call that A.G. WG. So they are producing a whole ton of documentation, and guidance documents, and research and updating all W3Cmaterial that addresses issues that are in the cognitive space.

So what’s in the cognitive space? The cognitive space includes things like neurodiversity. So that would be attention deficit disorder, dyslexia, dyscalculia, anything related to autism or Asperger’s. It also includes traumatic brain injury. It includes memory loss. It includes dementia.

Basically anything that your brain, where it might not be functioning at 100% either for temporary reasons such as situational depression, for example, or chemotherapy side effects, all the way to permanent disabilities. And the permanent disabilities can either be acquired such as traumatic brain injury. That’s always an acquired disability or they can be congenital like Down Syndrome.

And I have put in a link. Everything that you see that’s blue and underlined in this deck is a link. And so, that is the link to the current COGA publication, and the current COGA publication, in turn, is being used to inform new guidelines that are going into WCAG 2.2 and Silver WCAG 3.0. Okay, sorry, I got a little bit ahead of myself. So this is what disabilities does focus–does COGA focus on. Aphasia. I always forget that one. So that’s my own cognitive issue. So these are the lists of all the disability that COGA covers.

What types of guidelines is COGA going to bring us. First of all, there are a series of plain language requirements. You want to make sure that you’re using language in your website. So content, for all intents and purposes, that is at the level of your reader. And when it’s beyond the level of your reader, you want to make sure that you’re linking to definitions that your reader can find easily. So, for example, the word dyscalculia is not super well known to most people with 6th to 8th grade reading levels, so you would want to have a link whenever you use that word in your website, if it was included in your website, to a definition where somebody could read, “Oh, this is what dyscalculia means.” The second type of groups of guidelines that COGA will bring us, is clear purpose requirements, making it obvious to the users what it is that they’re supposed to be doing and what steps they’re going to be taking. You know, basically telling the user what the happy path is.

And the third set of requirements that are coming are the need to be able to operate without having good memory. So leaving more breadcrumbs for your users to figure out how they got to where they are, and more importantly, how to get back to where they are when they don’t–when they forget things quickly, where they don’t have good working short-term memory.

So those are the three different categories that are–guidelines that are currently pending, and I’ll get into more specifics about what we know about what WCAG 2.2 and 3.0 that include instances of these types of guidelines.

Okay. So now, moving out of COGA and onto WCAG 2.2.So WCAG 2.2 is currently–has its Second Public Working Draft out. It is still a work in progress. What we’re about to talk about is still subject to change,but it’s getting towards final. Originally, it is planned to be final in November. That got delayed a little bit because of COVID, and we’re looking at WCAG 2.2 becoming final in approximately June of next year. So that’s June of 2021.

And if you add the standard 18 months to when–that 18 months is not a W3C you have to implement this in 18 months guideline. That 18 months is a somewhat safe buffer range that we have seen in the United States, where once a standard becomes final, if you implant that standard within the next 18 months, chances are you won’t get sued. So that means 18 months from June of 2021, takes us either to the end of 2022 or the beginning of 2023, that you would have to have these nine new standards implemented by, in order to be relatively safe from lawsuits.

I’m kind of using some fudging words here, because of course, you can sued for WCAG 2.2 noncompliance, the day after comes out. But that’s not really reasonable, but reasonable doesn’t always factor into United States litigation. So 18 months is typically the amount of time before you start to see the new standards reflected in laws and lawsuits.

Okay, so there are nine guidelines, new guidelines that pertain to WCAG 2.2. Eight of them are A and A.A.Some I’m not going to cover the AAA guideline. I have a link to it in the references section. But typically, people don’t implement AAA guidelines. They’re fairly restrictive, especially with respect to colors, the AAA guidelines in general. And in the U.S., in particular, A.A. is the standard that everybody seems to have adopted. So the focus here will be on the eight new guidelines that are either A or A.A. And you can see I’ve mentioned in the link in each of these slides, whether it’s an A or double A requirement.

So the first new guideline is Focus Appearance. So this guideline is related to two other guidelines pertaining to keyboard focus indicators. One of the guidelines is 2.4.7, which is that you have to have a focus that’s visible. And one of the changes in WCAG 2.2 is that guideline in particular, is moving from A.A. to A.

So A is the dealbreaker. If you don’t do this, you’re making it not work for a whole ton of people with disabilities. A.A. is you’re making it hard. So that’s kind of the distinction between the two. So the other guideline that this is referencing is 1.4.11 which is Non-text Contrast. So all three of these combined relate to how you treat keyboard focus indicators for actionable objects. Okay. So the summation of all three of the guidelines put together, so not just the new one, but all three of them, you have to have a keyboard focus indicator. Nonnegotiable. That comes from 2.4.7, which as I mentioned, is moving from A.A. to A, in terms of requirement level.

Keyboard focus indicator has to have a contrast of 3.0 to 1.0at all times. That comes from 1.4.11, which came out with WCAG 2.1. And then finally, the focus indication area has to be thick enough to be able to see. So, the first requirement in 2.0 was you have to have an indicator.

The second requirement in 2.1 was, “Oh yeah, you have to be able to see the indicator.You have to have enough contrast.” The addition that they’ve made in WCAG 2.2 is you really have to see the indicator. So it added an aspect of thickness. So it either has to be at least 8 CSS pixels on the short side or it has to be 1 CSS pixel all the way around. You can’t make it any smaller than that. You really don’t want to make it dashed. Okay, so people have gotten creative in trying to be compliant without–compliant with the letter of the guideline without being compliant with the spirit of the guideline. Spirit of the guideline was people like me with glaucoma who are keyboard-only users, need to be able to see the darn keyboard focus indicator.

Because people were trying to skirt that by making keyboard focus indicators, you know, light blue or yellow, so that, you know, the designers just didn’t want it to impact what the website looked like. So then we added the darkness requirements, the contrast requirements. Then designers tried to use fancy patterns to again make it not so visible, and so now the guidelines have specific rules about thickness. So that is the first new guideline that’s coming with2.2, and also the related change to 2.1, making the keyboard focus indicator requirement moving from A.A. to A.

Okay. And then finally, the keyboard focus indicator can never be blocked by content. You’ll see that that is a trend that started in WCAG 2.1, with guidelines pertaining to popovers and it’s been extended into over the keyboard focus indicator, that you can’t block a keyboard focus indicator with a popover or with a dialog box or something, that’s just going to make it really hard for the keyboard user to be able to see it.

The next guideline that’s being added is what are calledFix Reference Points. So–and you’ll see that most of these guidelines’ additions come from pain points So the pain point for 2.4.11, which is the one that we just talked about, is keyboard-only users who use magnification. The pain point for Fixed Reference Points is for people with any degree of vision loss who use magnification or users with dyslexia who are using special CSS sheets to reformat the text, to put better spacing in or to turn off justification. And what happens is when you magnify it or when you add additional spacing, all your page numbering goes to heck. So if you are in a classroom setting or in a legal reference setting, somebody says, “I’m on page 37.”

For you, it might be page 53 because you’ve added that spacing or you’ve added that magnification and the page numbers have totally gotten out of sync. So you need to make sure that when you’re on your table of contents, and it says this section starts on page 37, if it’s really on page 53 on your–what you’re looking at, that when you click on that link, it takes you to page 53 and it doesn’t take you to page 37absolutes, because that’s not the information that you’re looking for. So there have to be fixed reference points so that people can get to what it is that they need to see in their environment that matches what somebody else is looking at it, even if the page numbers are different.

In the next item that’s being added is for drag and drop. All drag and drop operations need to be accessible from the keyboard. To me, that’s kind of a “duh” requirement. I felt that it was a miss in the previous visions of WCAG.Inaccessible drag and drop had to be flagged as a keyboard violation, and somewhat of a pillar violation, in that something wasn’t operable by people using assistive technology.If you’re looking for how to implement accessible drag and drop, Salesforce Lightning which is an open source design system, has good accessible drag-and-drop patterns, and I’ve linked to an article that explains how to implement them.

The Clarity Design System which is at clarity.design, it’s one of the–it’s the design system that comes from VMware that I work go on, will be having accessible drag and drop in a soon-to-be-released vision.It will probably come out before WCAG 2.2 comes out.And each one of these items, I think I may have mentioned it, but just in case I didn’t, these are all links to the currently proposed text. You can see that there will be comments in that saying open issues that need to be addressed. I’ve just tried to translate the spirit of the requirement into English on these pages.

So 3.2.7 to me, like 2.5.7, was something that was kind of a miss. It could be implied that there was a keyboard operation violation, which that requirement didn’t actually work for mobile.So, for example, you could have a hidden control, for example, a swipe left to delete in a native app, and there was really no guideline in WCAG 2.1that made that illegal. And you have to remember not everybody can touch their device.

Not everybody can use a keyboard, so you need to have a way from the keyboard to trigger hidden operations which then, Sip and Puff devices and switch devices use keyboard simulation to order–in order to access those, even though the user still is never touching a keyboard. So swipe left to delete in a native app is where hidden controls are most common. Advancing controls for a manual slide carousels. So if you have a carousel that doesn’t automatically move, and it’s got arrows that only come up when you mouse over to them, those controls are considered hidden.

So you need to have a keyboard controls or they have to be visible without requiring cover. So another way you could do it is making them persistently visible. How do you make them persistently visible? You could make that a feature that’s associated with the login, so that would come under personalization where you could have somebody set up things in their accounts saying, “I want closed close captioning turned on all the time.I want all hidden controls visible all the time. I always want to use a dyslexia friendly font.”Accessibility features that you could associate with the login, so that when the user logs in, all those features get set automatically. Okay, Pointer Target Spacing is another add-on from WCAG 2.1.2.1 had a guideline for what they called inadvertent activation, but it didn’t have a spacing. So that gave us a guideline of minimum size of 44 CSS pixel squared, but he didn’t talk about spacing.

Okay. So this addresses the spacing requirement.So it expands on the 2.1 requirement pertaining to the size.And also in–this was one thing that really frustrated me in 2.1. I lost the vote on this one. Originally, it was proposed to be a A.A. requirement and the minimum touch target size became a AAA requirement, which meant really nobody was obligated to implement it. This Pointer Target Spacing guideline is a A.A. requirement, so people will be obligated, for the most part, to implement that.

Hey, then there are three new guidelines in WCAG 2.2 that pertain to Silver. One is Finding Help, one is Accessible Authentication,and one is Redundant Entry. And you can see all three of these are A-level requirements, because you’re blocking an entire group of people with cognitive disabilities from being able to interact with your site or your software, if you’re not doing these three things.

So Findable Help, every single page has to have help available somewhere, okay, either how to get in touch with a human; how to contact the human, so a phone number or an email address; a self-help option, so context sensitive help for that page; or a fully automated contact mechanism. So you need to have one of those minimum on every single page. You know, probably in the footer. Although, WCAG is not prescriptive about how you do, how you implement the guidelines, just that the guidelines have to be implemented.

Accessible Authentication. So authentication meaning logging in,if it requires on all cognitive function test, you also have to have another method that doesn’t rely on a cognitive function test. Memory, which includes remembering a password, is considered a cognitive function test. So that means that to be compliant with WCAG 2.2,at the A-level, you’re going to have to have at least two methods of being able to log in.

The standard username and password and some type of secondary login, such as biometrics or sending a link or a code to a registered phone, so that somebody who has memory issues and can’t remember their passwords, still has a secure way of getting in.Okay.

WCAG, the next one, Redundant Entry. This is one of my pet peeves. I’m so glad that they implemented this feature, because to me, this happens all the time. So you try to log in on something that you haven’t seen in a year, the login fails, you press “forget password” to reset your password and it asks you to type your login again. It had the login. You already put it in when you tried to log in. The website had the information, but it’s making you type it in twice. It takes a long time for people with disabilities to enter in things, especially when they’re using assistive technology. So making people type things twice is not satisfying the spirit of being accessible. Failing to implement auto-population is not following the spirit of being accessible. So do two things are going to be part of WCAG 2.2 under Redundant Entry which is part of COGA.

And then finally, where are we on 2.2? The Second Public Working Draft is out.It’s anticipated to be final by next summer. And as I mentioned, in the U.S., that means you’re going to have about 18 months before you get in trouble in terms of litigation.

I’ll quickly go through Silver. As I’ve mentioned, Silver is the next evolution in the W3C guidelines. We took–and the Silver name came from the idea that it was just going to be called Accessibility Guidelines, but we took a vote and we decided to leave the WCin because it’s what people are familiar with. So Silver is WCAG 3.0. It’s more of a focus on functional need than is on guidelines.

So, for example, remember those three different guidelines that pertained to keyboard focus indicators? Those are all going to be grouped together. I’m responsible for something that’s being called content structure. Content structure will be the three different heading guidelines that currently exist grouped together. In terms of scoring, there will be a scoring function of how compliant you are, which is going to be more of a focus on being substantively conformant. Right now, as the VPATs and WCAG stands, if you have 5000 pieces of alt text and you have one little, teeny piece away in a corner that’s not working correctly, you’re considered to be noncompliant.

Here, the focus is on the absolutes of compliance versus noncompliance.
It’s more focused on can a user with a disability use this software? And there’s also going to be completely brand-new areas of guidance, one will be on V.R. and X.R., so virtual reality and extended reality.

And another area that’s being added is maturity modeling. This isn’t intended to be an exhaustive list, just to give you an idea of what types of things are coming in Silver and where it’s going to be different than the visions ofWCAG that we’ve had since 2006.
Okay. So resource summary at the end. These are all of the guidelines that are coming with 2.2.And I am happy at this point to take any questions that Amber, I believe, is going to pass those to me from the YouTube feed.

Amber: Yeah.

Sheri: And I’m going to drink some coffee.

Amber: Well, thank you so much. That was very informative. There are quite a few questions here about how you got started and volunteering. Volunteering. Can you share a little bit about your background and what got you interested in this?

Sheri: Sure. So I’m what I like to call really overeducated.I started off, let’s just say more than three decades ago with a degree in computer science. I went to CAL in the early ’80s. Then ten years after that, I decided that I wanted to go to law school. My third year of law school, we discovered that by middle daughter was losing her hearing.

She had a progressive hearing loss. So I had intended to go the anesthesiology of law, which is intellectual property, especially because I live in Silicon Valley. I was doing things like trademarks and copyrights and patents. I ended up going into advocacy for the deaf instead.And so I did that for eight years. And then, basically put myself out of business because I was suing insurance companies for failing to provide equal treatment for deaf patients.

And I won a class action lawsuit against Blue Cross, and everybody folded. And I was doing it through a nonprofit anyway, so it wasn’t exactly like I was making money hand over fist with these lawsuits. So I needed to pivot again, and that was just when accessibility was really starting to take off. That was about eight years ago, and I’ve been in digital accessibility ever since. So I think it makes, it’s a really nice intersection of what I love to do the most.

It’s tech, because if some developer says, “Oh, that’s going to be hard.” My response is always, “Would you like me to code that for you?” I mean I can actually tell when they’re trying to avoid doing something just because they don’t want to do it. You know, I use my legal degree to interpret the laws.And then, I also went back and got an MBA, so I also see the business perspective of accessibility and I could write really strong business cases for it.

So people automatically assume that because I’ve used a wheelchair since I was five, that that’s why I got into accessibility. But I actually got into accessibility because of my deaf daughter. To me, my wheelchair is just a mechanism of getting around. I don’t particularly consider that a disability. And then what was the second question? The second question was about volunteering?

Amber: Yes. So there’s a couple of people who have asked what kind of tasks do people participate in, in W3C Task Forces? What are the tasks that they end up doing? What is the volunteer experience like?

Sheri: Sure. So like I said, lots, and lots, and lots and lots of meetings, and a little bit of take away and go and do some research on your own. So, for example on the Maturity Modeling Subcommittee which I co-lead with David Fazio, right now what we’re doing is we have built a framework of dimensions and attributes, and everybody on the team has one dimension, and they are defining all the different attributes. So we are proposing, and this hasn’t even been reviewed. I have to be a little bit vague here because it hasn’t been reviewed by the Silver subcommittee yet.

That’s happening in about a month. But everybody has been assigned one of those things. So we go in, we put in straw man information about what we think the attribute should look like for that dimension. So let me give you an example. For a dimension of software development lifecycle, it might include an attribute of you have a software Q.A. plan that references accessibility and assistive technology. And then we get together and we meet as a group and we talk about each other’s work, and we wordsmith it so that in the end, it all looks like it was written with one cohesive approach by one individual, instead of actually being worked on by six or eight different individuals, because that’s really important to the end product. So meetings to discuss what’s going on.

We all work in Google Docs together and put in comments about each other’s work. We’ve refined the comments, then the Maturity Model Subcommitteetakes that and reviews it with the Silver Committee. Once it’s approved by the Silver Committee, then we take it up to the–what they call the A.G. W.G., the Accessibility Guidelines Working Group. Once it gets approved by them, then it gets published for people, for the general community to comment on. And at any time, somebody who is identified as a volunteer can look at any of the draft material in GitHub. We use Git for versioning all of our documents and that’s where we release from. So hopefully that answers your question.

Amber: What’s the time commitment?

Sheri: And like I said the first–

Amber: I’m sorry.

Sheri: Minimum time commitment is–yeah, that’s all right. No, minimum time commitment is probably practically about six hours a week.

Amber: Okay.

Sheri: It’s not for people who just want to pop in now and then and see what’s going on. It is definitely a significant amount of time.

Amber: Good to know. What’s the best way–someone asked what’s the best way to build yourself into WCAG expert?

Sheri: What’s the best way? So, I would say for starters, IAAP, the International Association of Accessibility Professionals has two certification programs right now and they’re about to add several more. So there is the CPACC, which is Certified Professional Accessibility Core Competencies. That’s for lack of a better phrase. The Accessibility Manager certification. Then there’s the WAS, which is the Web Accessibility Specialist certification. That requires significant coding chops. And then the third certification that’s coming is Strategic Leader in Accessibility.

So that’s people who are looking at implementing accessibility at the organizational level. How do you set up training programs? How do you set up support programs? How do you may sure your documentation is accessible? So certifying through those groups definitely demonstrates that you have a particular level of accessibility skills.

I write a lot. I’ve been writing twice a week now for two years. I’m up to, I think, 154 articles when I counted last week, on various different approaches to accessibility. So the last article that I wrote was about making sure that people use context when they’re identified what their alt text should be. So that’s a way that you can demonstrate your accessibility skills. I think building your accessibility brand on social media is really important. I wrote an article on that. You definitely need to have an accessibility elevator pitch so you can explain in 45 seconds what is it that you as an individual bring to an accessibility program.

So those things are all. And then, obviously doing presentations like this, and preferably recorded presentations so that people can get them on demand. That–so I submitted seven presentations to seven different conferences a couple months ago. Usually about 50% of my presentations get accepted. For some reason, six out of seven got accepted, so I’ve been really busy giving talks this month, but that’s another aspect to building your accessibility brand, of people being able to watch recorded presentations.

Amber: Well, we really appreciate you coming and sharing all the information with us. Those are all the questions we have time for today. But I’m sure that if you have additional questions, you can reach out to Sheri via the information that she has shared on the slides or via her Medium blog. Don’t forget to attend the next talk.

Sheri: Just–

Amber: Oh, yeah.

Sheri: Oh, sorry. I was just going to say drop me a–on LinkedIn, that’s a social media that I pay most attention to or put a note in one of my articles on Medium.

Amber: Okay. Well, thank you so much, Sheri.