Well, thank you all for coming. This is great. Now are my notes, they're not on the screen.
It's never good to go off and give a talk where it's like I cannot see what's on the
screen behind me so let's see if I can change that and there we go.
So my name is Mike Gifford. I'm with Civic Actions of a Senior Strategist there. What
I do there is a lot of work on accessibility and sustainability. I'm also a Drupal Core
Accessibility Maintainer and I like to do a lot of talks on open source and accessibility
and why it matters because I think that there's something unique with our community that we
can do, changes that we can make that make a huge impact. So I'm also just as a disclaimer,
I'm not a designer. I'm a PHP developer that sort of got, you know, watered into accessibility
and then suddenly had to deal with a lot of front-end stuff that I was not familiar with
prior to getting involved. So definitely appreciate having all the attention of the designers
and I've learned a lot from the design community I've worked with.
But a couple of things I assume that everyone here knows about open source. So there's a
great range of open source tools. We know that there's only, you know, here we're going
to be talking about a few of them but there's lots of really good accessibility open source
tools out there. I also want to go off and look at those. As you know there's a lot of
open source tools that are really not, they're essentially dead in the water. Somebody released
the project, they don't have a community around them. I think focusing on those pieces of
software around accessibility that actually have a group of, that are actively engaged
really does matter especially if you're starting to get involved with them. I'm also going to
use the short term OSS for open source software. As far as accessibility, I just want to remind
people that it's not a small portion of the population. We're not just talking about people
who are blind. We're talking about 25% of the population and if you look at permanent
tempering and situational disabilities you're talking about 100% of the population. Right
now you can probably all see the slides here but if the sun were in a slightly different
position there'd be a point where you may not be able to see that even in this presentation
just because we've got these gorgeous open windows. So we have to go off and think about
how accessibility can affect all of us. We also have to keep in mind that there's both
visible and invisible disabilities. Many of us, how many here know that they work with
people with disabilities? Okay, there's a lot of people who don't know because you
can't tell somebody who's colorblind, you can't tell somebody who's dyslexic, you can't
tell somebody who has low vision. There's a lot of disabilities you cannot tell by looking
at somebody from the outside. Even people who are legally blind, you may not know that
they're legally blind because they've learned how to go off and interact with them, or interact
with you. I'm also going to use the short term ALI which is a numerum, there's 11 letters
between A and Y and it's what it stands for. So Y, open source and accessibility. So bugs,
are a big one. When in most proprietary projects you don't actually get to see a list of the
issues that are there. You don't get to get an opportunity to see who made, what problems
have already been reported, but in open source communities basically every one of them has
an issue queue and often those issues are either identified as bugs which is an important
clarification. Accessibility issues should not be feature requests, they should be bugs
and they should be tagged for accessibility which many of them are so that people can
find them more quickly. With the Drupal community we've actually started the process of trying
to tag them for specific WCAG success criteria. The advantage of that is that you can actually
start to understand who is affected by the accessibility challenges and have a more fine
grained attempt to understand what are these issues, who does it affect and how serious
a concern is this. So we're looking at trying to do that with the Drupal community. Open
source communities are also really good because they tend to focus on trying to find a merit
based approach argument. So you're not looking for something that is who's the most popular
in the community, you want to try and find a best case argument for why this is the
best pattern for your project. So it's a really interesting experience from that perspective.
It's also neat because anyone can submit a bug, you just need often an account on GitHub
or Mantis or whichever else and that's a really useful feature as well because you can be
inclusive. Does anyone here know where to go off and submit issues to Office 365 when
you run into a bug at Office 365? Yeah, good luck. So the other thing is community interest.
It's really interesting being involved in the open source community because people want
to have others use their code base. It's part of the whole feeling of this. You don't release
the software so that other people can say, wow, that's really great software. You release
it so that people can use it and say, this is neat. I've learned from this. This is something
that I can use to benefit me. So there's an inherent interest in the developers getting
access to the code and engaging with the population. I think bringing people into the community
is something that's not easy to do but it's something that many successful open source
communities are able to accomplish. The Drupal phrase is, come for the code, stay for the
community and not that Drupal is the only content management system or a piece of software
out there. It's one you should all use, of course, but it's not the only one out there.
But that idea is something that's mirrored by many other effective open source tools
as well. Also, I think that it's something where it takes a village to maintain any piece
of software. The internet changes very quickly. If you want to go off and adjust in time and
be able to make modifications over time, you kind of need to have a large group of people
who you can engage with them on. Some of the accessibility issues are really very complicated.
The kinds of issues the Drupal community has dealt with, even the simple ones. Does everyone
know about CSS Display None? There's a really simple CSS code that is a huge accessibility
problem because designers and developers use it to go off and hide certain pieces of code
from the browser so you don't want to see it. It also hides it from screen reader users.
Trying to go from find a way to hide code visually but not hide it for people who need
to use it for assistive technology is a really big issue still. Technically, that's not
that complicated, but I'm sure that somebody here could write a PhD on how we dealt with
CSS and the challenges of CSS Display None in the Drupal community. Learning and sharing
is important, trying to be able to engage with others. What we learn in Drupal, we try and
share with WordPress and Joomla and Typo3 and others. That's something that we can benefit
from that is unique to the open source community.
Loads of conduct. Accessibility is part of the DEIA framework, the idea of diversity,
equity, inclusion. How do you try and make sure that we are bringing in people and having
a structure to go off and see that there is more diversity represented and you're not
just having a bunch of white guys speaking at events, it's really important. Having that
structure is, I think, really quite useful for accessibility. You don't need to necessarily
have this for a piece of commercial software, but if you're trying to engage a community,
you're probably going to eventually, if you grow big enough, have a code of conduct that
deals with feedback mechanisms, deals with bad actors, deals with people who act like
people do sometimes. We don't always act in the most dignified and organized and respectful
manners, even in our issue queues, so having forums to try and help moderate and manage
that is important. The in-person events are also quite useful. Again, you get to meet
people. I don't know if there's anyone here who is blind or low vision, but there certainly
have been other people at this conference who have seen who are either in a wheelchair
or using a guide dog. There have been some people here who have permanent disabilities
that we would typically identify as being more severely disabled. A lot of times community
events like this will think about that. There will be an accessibility page. People will
ask questions about the accessibility of the website. That also really helps. There's
a low cost of entry. This may be a surprise to you, but people who are disabled in our
economy are generally the least well-off. They're the poorest of the poor because they
often get a subsidy from the government. They often cannot get jobs. That subsidy is often
below their living wage. But just a quick joke, who here knows who the richest blind
user in the world is? Who's the richest blind user in the world? It's not Stevie Wonder.
It's Google. Google's a blind user. Can't see. Also, students are another element of
low income populations. If you want to attract students and engage students, open source
is a great way to do that. There's a focus on training materials, trying to bring people
in and to document things. If you can document an accessible way to do things, if you can
provide a best practice that addresses accessibility issues, it's much more likely that other people
will follow that practice going ahead. It's also really useful for a lot of open source
communities to have a community where you can reach out to an expert and get feedback
if you get stuck. The number of stupid questions I've asked that I've been able to get somebody
who knows a lot more than me to be able to help move me ahead so I can learn a little
bit more about the project. It's really quite important. Interoperability and standards.
When I first started getting involved in accessibility in Drupal, I thought, oh, because Drupal cares
about standards, I can probably go out and fix up the accessibility issues in Drupal
in, I don't know, a year or two. It shouldn't be a big deal because we care about open standards.
Here we are more than a decade after me being deeply involved in accessibility issues and
we're not there yet. We're further ahead. We're one of the most accessible open source
projects in the world, but there's just a lot of issues that you, it's a complex issue.
There's a lot of, the more you dig, the further you know, the more there is to do. It's an
ongoing process and the goal of accessibility really is to try and get, to be more accessible
today than you were yesterday. So that is, that's the goal.
And let's see. Yeah, if you're, if you're looking at an open source project and you're
trying to figure out how to go off and get acceptance and whatnot around that, just
talking about open standards and the value of interoperability, the value of, if you
build two standards that meet accessibility, it'll also be useful for future use cases
as well. Like, I don't know, how many people, how many people here are designing for voice
interfaces? Okay, you're not doing it now, but probably in the next FOS dam or one afterwards,
you're probably going to be designing for voice interfaces. If you build for accessibility,
it'll be much easier to, to interact with your voice interface because the semantics
are built in there and that's what really is important for driving voice interfaces.
Yeah, open standards and just having communities that care about this stuff. This is something
that, that it takes a while to go off and build up and maintain and to, to sustain that
sort of caring about it when you've got deadlines and ideas of, of, you know, yeah, product deadlines
and client deadlines, all that sort of stuff. So open accessibility reporting, I wanted to
talk a little bit about this. It's, this is a, in the US, VPATs are a much bigger deal.
So VPAT is the Voluntary Product Accessibility Template. This is not something that is very
common in Europe because VPATs are, were a good effort 20 years ago, but they don't
really cut the mustard in the rest of the world. They're not good enough for Europe
and they shouldn't be because they, they're, they're largely a sales document at this point.
But the, the WC3 went off and produced an, an evaluation methodology that's really quite
useful and was developed in Holland and was able to meet with HIDI degrees who went off
and developed the, the tool that, that is, is behind the WKGEM license. There's an interface
that allows you to go from, to, to guide you through the process of doing an accessibility
report. And one of the neat things about this is it has a, it has the ability to go for
write a, a machine readable document that it describes the, the, the website you're,
you're meeting, you're trying to address. So if you're looking at an institutional website,
if you have the ability to have a machine readable implement, like you can compare all
of the instances of all the software, all the licenses in one place, you can get a sense
of how your website compares to, how accessible it is today versus how accessible it was two
years ago. Just having that ability to manage that is really quite useful. And civic actions
went off and, and what, like the idea of having something for procurement that we need, that
could satisfy the VPAT requirements, but followed the model, the modern model that the WKGEM
implemented. And so we forked the, the WC, there was the WC3's WKGEM, AEM methodology,
and we created OpenACR, which is, is an open source platform for, for creating accessibility
confirmation reports. So if you're looking at providing reporting of different products,
this is, the OpenACR is a good format to do that, and it was developed and paid for by
the, the U.S. government, but it's, it's available for everyone. So cooperation versus
competition. I want to say that there's, there's a, the other neat thing about, about open
sources, there's a great deal of both, yeah, there's tension, but there's also, we collaborate
with each other, it's really quite nice. I'm on the, the Drupal, you know, Slack channel,
of course, but I'm also on the Twitter Slack channel, so people can catch me in either of
those places, not the Twitter, the WordPress Slack channel. So you can catch me in either
of those places, even though they're, they're often conflicting areas. So, but an area we,
we worked with recently was, was working with the, the European Commission with the, the
Wefor Authors cluster, and this was an effort to, to take the, the authoring tools and how
do we try and make authoring, the authoring, authoring tools better so that the authors
are able to go and, and to, to create, it'd be easier for authors to create accessible
content. Right now, most accessibility errors are caused by authors who use WYSIWYG editors
to go off and to create the content, and there, there isn't necessarily enough guidelines
to, to structure them into, to doing the, the, creating good accessible content. There's
a, there's something called the ATAG, where ATAG, which is the authoring tool accessibility
guidelines, and ATAG Part B is all about trying to make it easier for people to do the right
thing with accessibility if you're creating a content. And, and generally the authoring
interfaces are, are not given enough attention. This is the, the only study that I know of
that certainly the Drupal community has done to try and say, how do we engage with authors
to try and find ways to help authors create better content? That's not something that
is done often enough. And I also want to just phrase the, you know, the Drupal's, you know,
proudly found elsewhere. This, this idea that you don't have to build it all yourself. There
are times where you can pick, pick another project, like we don't have our own WYSIWYG
editor. We use CK Editor. So when we have an accessibility problem in CK Editor, with
CK Editor and Drupal, we push it back upstream. We're involved in engaging upstream with
other open source projects. So I want to say it's really important for people, I know I'm
running out of time, but the idea of having, engaging with people and having lived experience.
Like people with disabilities have a lot of, have additional ideas to share and to contribute
to, to your open source projects. So don't rely on the automated tools. Don't rely on
your manual testing. Don't rely on your third party accessibility auditor. Try and bring
in, I mean, those things are all good. They're all useful. But if you actually have people
with lived experience with disability testing your, your interface, you will have a much
different experience. You will have something, you will learn a lot more. And you can't
necessarily assume that everyone with a disability has the, like not every blind screen reader
user is going to have the same experience. You're going to, you know, they're, you're
just like regular people, they're going to have a different experience with the interface
and they're going to use things differently and navigate differently to, to manage the
interface. Yeah. So the more diverse people you engage with, the more robust and, and
structured thing you're going to have. So it's definitely useful there. Talent is another
big one. Thinking that, that you, you have, you know, open source projects need talent
and there's a real need to try and, and build up and to, to involve, you know, with those
people with a range of different skills and requirements. But also people with disabilities
are, are, are often very qualified but are restricted from, from working for, for even
for tech projects. Whether that's because they, they don't want to go into the office
or they, because it's too difficult or ornerous for them to work with somebody else's IT infrastructure
or because there's, there's the interfaces that they work with are not, not built for
accessibility. There's, you know, there's also often not a culture of, of addressing
and including people with disability, disabilities within your organization. So, just making
it so that you're, you're as much as possible removing the stigma and seeing disability is
not something that you have to make special adjustments for but it's really a, a point
of innovation and a point of, yeah, it's a learning point for everyone to go out and
build better products if you have people who interact differently with, with the web.
So sort of thinking about that, that, that talent aspect when you're, you're looking
at your organization. Innovation, we've got DQ's acts, we've got tools like Luxembourg's
Simply Alley PDF caller. My slides are all available so all this stuff is going to be
up online. There's a tool called Alley Watch we're using that right now which is doing
some incredibly fast scanning of websites. We're looking at being able to do government
wide accessibility scans. We're also seeing tools like Sally and Editorially which helped
to go off and support the authoring environment to give feedback to authors who are in accessibility.
I'm a big fan of Microsoft's accessibility insights. I got to say when I went to their
office I was shocked at how amazing their team was and how they were doing so much
stuff the right way. I was like, I, I did have to tell them that I was in the belly
of the evil empire but was really impressed. It was, it was a mind-blowing experience.
Also the, the, you know, NDDA is an excellent screen reader developed by two blind developers
in Australia. Like think about the money that's gone into tools like JAWS and, and voiceover
from, from corporations and, and governments. And yet you've got two, two people who believed
in open source that were able to go off and build a really strong, you know, screen reader
from that. And yeah, there's other stuff that's next but you're going to have to go off and
read the slide later and get into that. But yeah, there's a lot of, of, of, of Andrew
Brice tools that are built on open source tools and, and there's the ability to scale
and to, to push up software and, and to engage with accessibility in your CICD pipeline is
definitely something that, that is more and more accessible. So much easier for all organizations
to deal with. And now, if you have any questions, please let me know. Is anyone, anyone using
any accessibility tools? We ran some accessibility tests and, you know, it amazed me how, just
it's, for me doing accessibility tests for the first time, I was told the mind-blown
and how the information was available and how to conduct these tests. Right. Really,
like, you know, we had to go to YouTube and, and, and that kind of thing. You know, really.
And, and you mentioned that one of the best ways of testing applications and interfaces
is to actually get, you know, people who have disabilities, ranging, and, you know, there's
also disabilities to actually come in and support. Do you, do you know of any resources
where we can learn how to do, moderate, to do accessibility tests on, you know, people
with accessibility issues? The, the, so the question is, how do we, how do we learn how
to go off and do accessibility testing? And how do we learn to do usability testing with,
or usability research with people with disabilities? So, in terms of accessibility tests, I mean,
there, there are some tools out there, like you can look at, if you look at Microsoft's
accessibility insights, there are a series of videos associated with that. As with the
Wave Toolbar, they, there are ones that can walk you through that, but they're, they may
not be as prominent, they may not be a, what's your first step to get started? So, but they
do exist. And there, we have a lot of accessibility documentation as well, which you can find on
our, our sub site there that I think points to some of that. But, but it is a bit of an issue.
As far as the, the, the usability research, I was just reaching out to Fable, the Fable
Tech Labs folks, they do some really amazing work with people with disabilities. And the
thing is, is that people often expect to have, to have people with disabilities do this for
free. But they, they, they don't have a lot of money to go off and sit around and, and
to, to do usability testing. We really should be assuming that we're paying people with,
with disabilities to do these tests. And, and so by engaging with Fable, you will be paying
people to go off, people with disabilities to go off and to do these tests and get live
feedback from people. And I think you can learn a lot from that process. Not that you
always need to use Fable, but it's a, it will help you get some insights on how to do that.
Any other question? One more question? Okay. Yeah.
You had this, I mentioned before and I was thinking that it's kind of a thought that we have sort of
a range of people with, I don't want to kind of rank people in a way, but you have a scale of kind of different
life experiences, let's say. And then you have also a different scale of like feedback and
experience of like how they experience the software. So like when you do accessibility
testing for blind people, you know that there are these difficulties. And I think it's also
like very big thing to have a lot of neurodiverse and that kind of stuff. Yeah.
Also getting those feedback from the people who are usually maybe more quiet in the crowd
and to have their experience also. So it will be, give kind of a lot broader experience
of how do you make the software better? For sure. I mean, there's a, I didn't raise neurodiversity.
So the question was about neurodiversity and how do we try and make sure that we encourage more
support and testing and engagement with people of different neurodiverse backgrounds. And absolutely.
And it's everything from cognitive disabilities to PTSD to looking at people who have issues with
dyslexia, like there's a range of different, you know, disability people have. One of the things that
the WKG has really failed on is they've sort of allowed us to think that you could have one
sort of website to solve all of your issues. And I'm baffled at how many websites don't provide
support for even dark mode. Like all of our browsers and all of our system technologies
provide support for dark mode. We've got SVGs and other tools that can provide excellent support
for dark mode. Why are design systems not have support for dark mode? Generally they don't.
Why aren't we trying to go out and build for that as part of our expectations? This is something
that would help a lot of people, even if they're people who just are spending too much time in
front of the screen and want to be able to have a little bit of a less intense experience,
especially in the evening. We should be building for that. And it's something that I hope we do
more. And I think that that will help a lot of people with neurodiversity issues. But also just
realizing that there's a tool that was built by the IDRC, which is the Inclusive Design
Research Center in Canada, that's called the Preferences Editor. And it allows you to go off
and swap your fonts, your colors. You can go from two columns to one column. You can have a table
of contents that explodes. And my time is up, so that's all I have to say on the subject.
You can always contact Mike on all these things that he put up and also just talk to him after.
So thank you for your questions for that.