Don’t forget to subscribe to our to stay up-to-date. You can also leave a comment on individual videos. Please note, we review all comments before they’re posted. You can find out more at .
Blue Beanie Day 2021
Recognising web standards as the foundation for accessibility for all
Video sections
00:00 Introduction
02:30 What is Blue Beanie Day?
04:00 What do we mean when we say accessibility is a feature?
09:51 Video: Everyone is different
13:59 What we should know about accessibility?
22:58 Where do we go from here?
34:13 Questions and answers
Transcript
Danielle: Alright, let's try this again, thanks everyone, so we'll talk about what Blue Beanie day is. What we mean by accessibility is a feature... we're going to talk about how accessibility isn't a feature, we should talk about what the opposite means.
What happens when we treat it as a feature? General knowledge about accessibility, so we're not going to go into what WCAG is or any of the pieces that we've talked about before. I think the majority of you have been in the sessions before and I can definitely give you resources if you need them, but just other things that we haven't necessarily had a chance to dive into before in other presentations - understanding where do we go from here?
We can talk about how we shouldn't be doing something, but it doesn't really help. Great, if we don't know how we kind of changed our language, how we start incorporating this in Salsa and with our clients, etc. So I want to talk about that. We’ll talk about what inclusive language is and maybe try to change a little bit of our behaviours and what we say and then I just wanted to give examples of exercises on inclusivity.
I promise I'm not going to make anybody split into groups today or anything like that. I just want to make sure everybody is aware that there are these exercises out there, or even if it's just something that you read to get an understanding of what else you can do that's important as well and then having time for questions.
So before I go into all of this, there's something that I want to say that I think is really, really important. We're all here to learn, so I might say something that really hits a nerve with you. strikes a nerve, you're like, “oh my gosh, I've done that and I'm learning, that maybe I shouldn't have and I feel bad” or it might make you feel something.
There is no blame here, there's no shame, there is nothing of the sort. There are certainly things in here that I have done as an accessibility analyst and consultant that I am still learning, and I've even done it when I've presented to all of you and at conferences.
This is always a learning opportunity, so I just wanted to make sure that it's very clear that there's no judgement or anything like that. Just be willing to sit with it and know that this is a place and a time to learn.
Alright, and so with that, if I could get to my right slide... So what is Blue Beanie Day? So it was started in 2007. It was originated and kind of the brainchild of someone named Douglas Vos. He worked at HP, but it really became popularised by Jeffrey Zeldman. Some of you may know him based off of his work with designing with web standards, a very popular book and something that he has really continued to evangelise.
And the day really started out about recognising web standards and making sure that we raised awareness about web standards as well as making sure that we were fighting what's known as web standards apathy. Essentially, that's meaning that we know that web standards is not just like somebody decided that they were best practices, just felt like making people have to abide by some rules when they were coding or designing etc and that it's there for no reason.
There is a reason why those web standards exist and making sure that there is that kind of constant reminder and that it's being talked about. So how did this end up becoming important for web accessibility? So having correct web standards is a foundation for accessibility, so making sure that you're coding to all of the web standards will really help you make sure that your site or application is successful.
So what do we mean when we say accessibility is a feature? So essentially, If we were thinking about building a site and we said, ok, I want to create a blog listing page or our clients say that to us, most of the time, it becomes one or two tickets, of course we talk about it a little bit, but it goes into in progress, we've talked about the requirements, it's part of Sprint planning, it gets done. We don't really think about it again, but it’s not necessarily part of an ongoing process, and so it ends up being treated somewhat like a checkbox item. It's a one and done.
There is a possibility that is something where instead of this listing page, we actually want these ten other requirements first and write that listing page or whatever functionality we're talking about keeps getting prioritised or, I should say, actually deprioritised, and maybe sometimes it's not even done anymore.
And so, essentially, it ends up falling off the table completely, and so when we say accessibility is a feature, that's very possible to have happened and that's exactly what we're trying to avoid. And then there's the fact of, it doesn't focus on the whole picture, if we're looking at accessibility purely being a feature.
We need to think about the people aspect, and we sometimes forget that there are people, because we keep hearing WCAG 2.1 compliance, we have to comply. It's all about making sure that we're meeting these requirements of compliance and so that is really what gets drilled in, again, we were talking about how I've learned things.
I'll completely say that I've done that on projects too like, “Team, we need to be WCAG 2.1 compliant.” When we use that language, it really takes away the human aspect and so even, again, in terms of learning thing, I probably shouldn't have said able bodied people. We should say people without disabilities and, so, because again, that separates us and it's not meant to separate. In this presentation, I'm going to call myself out too, because it's all about learning.
So people with disabilities don't always want the same thing from sites. People without disabilities also don't always want the same thing from the site, so why should we assume that people without disabilities do. Again, that language. Disabled people should be people without disabilities, so really, just making sure that we're thinking about it from the human aspect.
And, if we need to simplify it, we wouldn't say “ oh, usability is a feature or QA is just going to be a feature or hey, let's just do development as a feature,” right? It's not. It's part of the whole process, and so we really need to just try to shift that thinking.
So what happens, when we treat it as a feature? I'm going to use the word unintentionally so many times throughout this presentation it's not even funny, but what ends up happening is we end up promoting ableism and we end up promoting discrimination and we make people feel less than.
And I'm going to say something that, I just admittedly might make people feel a little bit uncomfortable, but we would not be building sites purely for people that are, I'll just say people who are white or people who are straight, people that maybe aren't part of marginalised communities. It makes me uncomfortable to have to say that. Like we would never do that. That's not the way that we are. We would not segregate, we would not discriminate, we wouldn't do any of that, so why does it seem sometimes like we're doing that and really only thinking about people without disabilities? One isn't better than the other.
One does not deserve more than the other, right? It's all about inclusivity and just making sure that we're really thinking in that way and, I will, a little bit later, talk about the fact that I have an invisible disability. I will share some of my experience, but again, like I also want that to be a choice. I don't want to have to come out with that, just say “hey, like, look at me and so that's the reason why we should be doing this.” We should really just be thinking about it from a human perspective.
And so I put in an example that sometimes we hear, and for the record, I want to say that this is meant globally. These are not things that I've necessarily heard it at Salsa, so I'm not ltargeting people or anything like that. I just want to make sure that's very clear as well, but a lot of times, we hear, “Well, we need to do that 'cause it looks better that way. The design just looks better that way.”
Well imagine if that even though it looks better that way, that it's not inclusive and accessible. We've automatically prioritised the fact that something might look a little prettier over somebody's ability to access that information. And so it's really changing that mindset.
As we treat accessibility as a feature, it is less about kindness and inclusivity and more about that compliance, and something that we're being forced into. And then again, as I've already mentioned, it gets deprioritised when we're running a little bit behind.
So there is a three minute video I wanted to show. I have been told that it works when I play in the presentation, but I'm sure somebody will come off mute for some reason if it doesn't end up showing or if you can't hear it. So just let me know.
Everyone is different. We live, work, play and interact in our own individual ways. Many of our experiences are influenced by our senses and our situations.
In the online world, this means how we see, hear, move and think can vary greatly. That thing you just did on that app? Someone does that in a completely different way.
When you're planning your next digital creation, think about your audiences’ preferences and how varied those experiences may be. Don't cut someone out just because you haven't prepared for the way they might interact with your creation. And most of all, make it easy. This is what being inclusive is about: making sure that everyone gets to do what they want to do in a way that suits them.
Here are a few things to keep in mind. Some people may have 20/20 vision, but some might find that blurry or may see colours a bit differently from you or me. Some folks might need to bump up the text size a lot to read it, and some people may not be able to see it all and will listen to content read out aloud to them by a screen reader.
So, make sure you have enough contrast - let your text to really pop. Use a bigger font, make it easy to see and easy to change when needed and coded correctly so that it makes sense when a screen reader reads it aloud.
If you're using sound, not everyone will hear it, and some will want to turn it off, so make sure you're providing an equivalent way to get the message across, like a transcript, captions, or sign language.
We all move differently. Some of us can easily use a mouse or swipe on a touch screen, but not all people navigate in the same way. Some people use the keyboard to go through everything linearly on a page. Others might use a head-stick or an eye tracking machine to perform that same action.
Some will need more time to get things done, and for some people it might hurt to move, so make it easy to get around your creation. You should be able to use a keyboard as well as a mouse to perform any action.
Not everyone will understand things easily or in the same way. Every brain is wired differently, so some people process information faster or slower than others.
I think we lost audio.
Some people just might need more time to process information and act on it. Don't rush them. Write your content so that it's simple and clear. Make it as obvious as you can.
As creators of digital experiences, our mission is to make sure our users can do what they need to do. We're all different and we should respect those differences in ourselves and in others.
So plan for their success. Be inclusive. That thing you're creating, that you want them to use, build it to help them be awesome. They’ll love you for it.
Alright, I'm sorry about the sound for few seconds, but I think everybody gets the idea of what we're trying to say - that it's extremely important to make sure that we're being inclusive and that we need to think about all of the different ways that people are using our sites that we’re building.
So if we think about what we should know about accessibility, some of these might be obvious, but it's also important to make sure that we're saying it.
So lots of disabled users or people with disabilities, again, changing my language, making sure that I'm being inclusive, do use the web, right? We used to hear a lot of “Oh well, I don't have any people with disabilities using my site”. Well, how do you really know, right? We don't have ways to necessarily track assistive technology and, honestly, we shouldn't need to in order to make sure that we're focusing and caring about accessibility.
The other thing is it used to be about “well, if somebody who doesn't have vision isn’t using my site, I don't think they are.” And so it's a reminder, especially from that video that it's not just about vision, right? We have cognitive disabilities, we have auditory, motor. There's all of these different things that we need to consider.
Something else that was, I would say a lot more common earlier on, I guess I should say in the web, versus what we have now is people trying to create different experiences based on somebody's disability. So first of all, we need to make sure that our entire site is accessible to all people. But the other thing to keep in mind is that some users might have multiple disabilities, so it's possible to have an issue with your vision but also have an issue with a motor function as well.
So it's not something where we can bucket people. Like, I think about me. Let's say if there was a website for people that had dyed red hair and another one for people that have blue eyes.
Well, I fit into both of those, so I'm being forced to choose now. Obviously not the same thing. That was just an example that we shouldn't be making people choose between which experience that they should have.
The other one that I hear so much. “But it costs so much to do accessibility.” It actually doesn't. If we do it from the beginning, because we're thinking about the entire experience and not waiting until the end, so if we do look at this from the very beginning, then the cost will be less.
And also, even if it does cost a little bit more, is that more important than caring and showing that you're being inclusive? Maybe it does, but hopefully not. it's really the focus on people.
But then again, we also have to think about the fact that if we're not including accessibility, same thing, right? If we were to do no QA whatsoever, we would need to completely refactor, potentially, a lot of the site, and so that does end up costing a lot more as well.
Because it's not necessarily just about the code. It's also about the fact that we might have to completely rethink the design of certain components and actual usability.
So this is a really big one. Again, I have said this myself in terms of an accessible site “s this site accessible? Is the document accessible?”
There really is no such thing. And what I mean by that is it's kind of like, are we releasing a site without doing QA? We wouldn't do that, right? Or are we releasing the site without doing design. That's not something we would do.
And so accessibility being included in the very beginning means that we are releasing a site or we are creating a document. Accessibility should just be part of that.
And with that, accessibility isn't just about development. I think there's a lot of focus on that. “How do we make sure that our code is accessible?” But we need to be starting from the very beginning, before design even begins, about how are we going to do interactivity if we're worried about videos and the ability to create good captions or transcripts, maybe we don't include videos at all, right?
And that includes a lot of the conversation in not just design, but again, all the interactive elements. It might go into our HCD, so Human Centred Design, User Centred Design, all of those different principles.
Another piece we hear a lot of, “Well, I did automated testing”. Well, that's great. I'm never going to get upset at anybody for doing automated accessibility testing, but would we ever do automated QA testing and just be like, “Ok, we we tested the site, we're good to go!”
People would probably be up in arms about that - that we didn't bother to go through the process and to do manual QA, if we weren't thinking about all those instances of what happens if you click on a button or if you tab on a button and what happens.
People would be probably very upset. So again, thinking about the inclusivity and the fact that we need to make sure that everyone's experiences are included.
Another one that's really important. Imagine having a site without a working UI. You can't click on buttons. You can't navigate around. You have no idea what the error messages are.
I'm sure some of you might have had sites like this, because they're completely broken or even when you've been testing things as they are in development. It can be really frustrating and it's “ well, I just don't want to use this anymore. They haven't bothered to make sure that anything is working.”
Well, if we're not focusing on accessibility, that can be exactly what we're creating for someone. So thinking through that even though you as a person might be able to actually go through and get what you want, doesn't necessarily mean that other people are.
Accessibility helps everyone. It does improve the user experience, and it often makes sites easier and more convenient. A lot of people use captions, even if they don't need them. There are even examples, like if you have an iPhone and you have the big buttons. Those are really helpful to everybody, even though originally they were created for accessibility purposes.
Remembering again that there are benefits outside of inclusivity, so you're making sure that you have more users. There could be more revenue, right? If we're looking sometimes at our clients, it's actually better access to services, and it also helps your reputation. I'm certainly not all about branding, but it is good to make sure that it's clear who is really focusing on inclusivity.
The next one - I hope this doesn't make anybody want to scream or cry, but just because you have a WCAG compliant site does not necessarily mean that it will be fully accessible.
These are just criteria. They are guidelines, but that won't necessarily help you. Like is your alt text actually super descriptive? Will every user that has a disability, will they want to use this site in this certain way?
So remembering that it's about individual users and it's really thinking about that full user base as opposed to trying to group into people with disabilities and people without disabilities.
We do user research all the time and we don't say, “OK, well, you don't have a disability and so therefore you all want to use the site in the same way.” Similar to what we said before, making sure that we're thinking about it from that holistic experience.
We should be using HTML5 before adding ARIA attributes. So for those of you that aren't familiar with ARIA, basically, they are attributes used in development to help make a site more accessible.
They can help read messages out loud for error messages, etc. There is kind of a joke, not necessarily a joke, within the accessibility community of “the first rule of ARIA is to not use ARIA.” But, really, that's because of the fact that using web standards and best practices first is where you want to focus and then you want to add on the extras after that.
The other piece is that you don't have to be an accessibility expert to work on accessibility, and you also don't have to be a person with a disability in order to test for accessibility as well.
And then the last thing. We shouldn't be testing for compliance, and I put a little smile here just because I know sometimes it's happened, but there is no such thing as an accessibility Sprint. We don't focus on accessibility for two weeks, right? And say, “OK, we're done. We've got it.” It really is incorporated as part of the process.
So where do we go from here? Having an accessibility first mindset. That really starts from the beginning. I know that I've continued to say it, but hopefully that helps fill in the message that we want to make sure that we're really focusing on accessibility first and foremost. Taking what you learned or little pieces and telling other people at Salsa or former coworkers, clients, friends, anybody who you work with and who you're talking to about digital experiences and digital transformation is really important to be able to have those conversations and to be able to teach others.
I'm not going to repeat it again, but it's really just starting those conversations early and carrying that throughout. Reading the blog posts that we have. For our Salsa site, I do have a resource section on that, as well as other posts, and learning more about the accessibility starter kit that we can use both internally, as well as with clients.
I am putting something out here that I will totally admit I've not talked to Alfred and Paul about, so, sorry guys, but surprise. But potentially representing accessibility differently in our feature matrix. So what I mean by that is helping change the conversation and instead of necessarily having that as part of a cell. Is having something that when we're talking to clients and this doesn't just have to be pre sales.
This can be when we're talking to clients and working through this in discovery as well is - we do not have this on our matrix because we take accessibility from the very beginning all the way through the end. Here's our process - really helping kind of change and shape that language.
And so, again, it's not something where we're just showing that we're ticking a box. We're showing, yes, absolutely, we are going to make sure that accessibility is included, but here is the way that we do it. That being said, because there has not been alignment yet, please don't change anything that we're doing. It's just kind of an idea of things that we can do internally as well to make those changes.
Obviously coming to presentations and learning is another thing that you can do.
And then there are some other pieces as well, so cultivating empathy. So I mentioned that I would explain a little bit about what I've been through with somebody who has lived with a disability previously and now as well. So when I was three, I was very, very sick and I ended up getting ear infections and I was not able to hear the sound R when I was being taught.
And because of that, from the time that I was 3 until about 12, I would say, my “R” pretty much sounded like W's. Kids are not very nice, so you can imagine how that worked out for me. But it also made it so that I just didn't really talk that much.
So anybody that knows me now just blame those nine years that I didn't talk then for what happens now. (laughter) I get told that I talk a lot and so probably the fact that I didn't talk for almost nine years is a good reason for that.
But also in addition to that, about 20 years ago, I got into a car accident. I had a cement truck turn in front of me into a neighbourhood entry. I had nowhere to go but straight into him, and I now have nerve damage all the way from under my left eye all the way down, arthritis in my hands, back pain, lots of just chronic pain issues.
I spend pretty much thousands of dollars on recovery every year just so I can do triathlons still and stay active. So why do I tell you all of that?
Certainly not to have anybody feel sorry for me, because that is not at all what I want. What I mean is I can talk about accessibility until I'm blue in the face. But unless if you are in my shoes, you won't know exactly what it's like to have that disability.
Same thing with if you’re a part of other marginalised communities or other disabilities, etc, right? We don't know exactly what it's like to be in anybody else's shoes, but, at the same time we can listen to people's experiences. We can try to understand as much as we can.
And again, it's kind of like what I was saying before about teaching others. If we hear somebody that maybe is not using the best language unintentionally, right? I've already corrected myself multiple times in this presentation or if there's a situation where we see somebody trying to deviate from what is best with inclusivity, that we can have those conversations with each other and try to draw on that empathy. And so that's one thing that I wanted to note.
The other, again, I've done this in presentations, is using statistics when talking about accessibility. So one in four people has a disability or this many people are colourblind or this, that and the other thing.
And really, what ends up happening is it's not that you're taking away from the inclusivity, necessarily. It's more about the fact that we're really focusing more, maybe sometimes accidentally, on a smaller portion of the population. Because if we're talking about a percentage of people who are colourblind or if we’re talking about something else like that, then we stop thinking about the whole and we start focusing on a smaller group of people.
So I said I would say unintentionally over and over again. That's one of those things that is unintentional, but that can be what happens when we talk about statistics.
We can perform an audit of where we are within Salsa with our business development in presales, design, product, development, QA, kind of everything and see how we feel like we're doing.
John and I can certainly help with that, but I also don't want accessibility to just be me and John, right? Just because I was on the accessibility team, just because John pretty much is the accessibility team now, with some support from me, I don't want it to just be about the two of us.
I've definitely seen that growing. The health.vic team, we've done some great things there. I don't know if he's on but I’m calling out Alan Cole. He’s done some fantastic things. There are others within the company that are really starting to grab on, and I know a lot of you are interested, right? That's why you're here, and it's great to see that grow. So just know that it doesn't just necessarily have to come from the accessibility team.
We're here to help support you and teach you, so that we can do all of these things. Also, when we do that on it then improving our processes.
You can incorporate suggestions from us, but really, we'd love for those suggestions to maybe come from you all, and to say, “hey, John, Danielle I'm thinking about this or this is what I've learned, I'm just really curious on your thoughts about this. What do you think for this project?” We want to make sure that it's a Salsa team thing and again, not just two people.
So in terms of coming soon, we do have a lot of resources on accessibility that I don't feel have necessarily made it out to everybody, so we will be having a playbook on Confluence and just understanding a little bit of a roadmap of what we're looking to do and then having some getting started sessions with EMs, Devs, QA.
I’m sure we’ll have more as well to make sure that everybody feels comfortable getting everything included into our projects.
So we are almost done here, but, and I will again call myself out, that this is not necessarily accessible with the way that it's done, so I will be turning this into a table but wanted to talk about it.
Some of the negative terms and affirmative terms. I had said disabled people when it's better to say people with disabilities. I mentioned able bodied, instead of person without a disability. So I still have things that are ingrained in me that I am trying to change as well, but just note again, if you use a term that maybe is considered negative, it's ok, right?
We're all learning. There's no blame, there's no shame. It's just figuring out, from a societal perspective as well, things have definitely changed, and how exactly do we start incorporating some more of those affirmative terms and something that's a little bit more positive into our language?
And then one of the last things - exercises on inclusivity. Like I said, we would not be breaking up into groups or anything, but I wanted to let everybody know that these exist.
They are a part of Microsoft's inclusivity toolkit that you can download. There's a lot of different exercises and a lot of different activities that they have. And information. It’s great, and I do have a link to that in the resources section here. But it really helps to start understanding.
The first part is really about HCI or human computer interaction - understanding where there might be some downfalls there, whether or not you are a person with a disability or a person without a disability, and then they even have a video here about accessibility, sensitivity training, or just some basics to understand more about accessibility and what people who have temporary and permanent disabilities and what they go through, as well as just more information about how to maybe interview people and get to know more about them as people and what their experiences are.
So in terms of resources, we do have video. There's a guy who pretty much tells you everything you would ever want to know about what it's like to live without vision. There are some things that I wouldn't even talk about at work that he goes through because he knows that people are curious. So a really good video to understand that.
These are DrupalShorts that happened this year, so I did one on incorporating accessibility into the project lifecycle. And then did a presentation, I guess about three weeks ago, with Philippa.
I also have some links to the Microsoft Inclusive Toolkit as well as our accessibility starter kit and then lots of blog posts that we've done for Salsa and there's also one on A11y myths.
So accessibility is also known as A11y because of everything in between the A and Y. There are 11 letters, so you often see that acronym. I think there were about 23 there, so some of them were incorporated in this presentation, but some of them are just extras that are good for everybody to know.
So with that I have talked a lot, but I'm very interested to hear any questions or comments. I know we have, looks like about 7 minutes. I'm certainly able to stay on a little bit longer if needed, but just wanted to open it up.
Right, Greg? I see that you have your hand raised.
Greg: Boy, do I have things to ask and say so first of all, thank you for putting this together. I'm not sure we're going to have the time I'm... I know that this presentation was focused on accessibility, but I'm glad that you mentioned unintentional discrimination or invisible disabilities, I should say, and it's it's funny how sort of like if you live in your own bubble
You tend to sort of like neglect or ignore things until they're being brought to your attention. And one of the sensitivities that I have coming from less fortunate countries than Australia is people that have a different social or financial status and this comes as an afterthought.
So, see how you mentioned that, ideally I shouldn’t say, you… the site wouldn't, shouldn't go live if it's not accessible, right? But that incurs costs no matter if you do it beforehand and it's less or after that fact is more, so it sounds sort of like it has its own bubble, because our target audience are enterprise and government which have budgets, but there are either less fortunate countries with businesses that still want to thrive and have an equal chance.
So they need to have an online presence so that, it's not a matter of cutting corners before they get an online presence, but rather, they need to survive or get a start to put on the business.
So it's a reality that sites are being brought online daily which are not accessible. For example, I admire Australia a lot because there's a lot of community languages and the Australian government does a very good job at translating pages into multiple languages.
So now we're making the assumption here that everyone speaks English, but immediately we have excluded people that don't speak English, right? So Salsa in these systems shouldn't go live with it if the site wasn't translated in multiple languages, right, 'cause we're discriminating or excluding people?
But Salsa needed to make a decision that our target audience is people that speak English or whatever. So they made a decision. That's how they built the site. These are points that I wanted to make in food for thought, but I have also a question, right?
So there was a heated discussion in an open source community that I'm a part of which had to do with accessibility. There was a person that was insisting that it is a feature, and I don't want it or I don't want to have the cost or don't want to build a site with accessibility.
The general feeling was that we are not going to build a product that is open source and less accessible. Like we're not going to make it a feature that you can enable or disable, but my question to you is, as technology progresses, is there a way or other thoughts of adding features that let the technology know if the person that is accessing the technology does have a specific need, so that developers can take that into account?
Are there efforts being made towards that end? And I know we shouldn't make sites that you can turn on or off accessibility as a feature, but I'm saying I'm trying to bridge the gap between those that say I don't need accessibility features now and I want to have the option. So is there anything that you're aware of being done with that?
Danielle: Yeah, so not particularly, and I know that we talked about how it's a little bit different from an overlay, but the issue is that if we do start to…sorry I'm trying to find the best way to phrase this.
If we do start to say “hey, this person is using assistive technology,” whether it's a screen reader or whatever it is, eye tracking, we are actually starting to invade their privacy, right?
We have privacy laws and PII and PIA and everything else right for a reason. And so we're basically getting into their medical needs and forcing them to disclose that it's –
I know this isn't exactly where you're going with this, but I think you have seen right that, all over the news, across the entire world, that COVID sites were not accessible.
Well, now it is a huge problem or even medical appointments whenever - what if you needed that and all of a sudden you can't use it, right?
Doctors were just crazy busy, so you couldn't call them so then you're forced to disclose to somebody else what you want medically in order to be able to actually get something done, right? You have to give up your privacy in order to be able to move forward.
Greg: I understand what you're saying, but I'm approaching this from my… an open source sort of like trying to adapt and make the world better for as many people as we can.
And I understand what you're saying with regards to privacy, but we already have in place means to detect, for example, if a person's language is left to right or right to left, and then the browser adapts.
So I'm putting that from a technical sort of perspective and not a discrimination or “I want to know information about your situation,” so I'm, if this is done properly or anonymously, I'm not sure how that's invasion?
Danielle: It's not the same thing though, like having somebody’s language known is not the same thing as their medical information essentially being brought up.
Greg: Yeah, I know people are equally sensitive about that, right? Like why should I disclose information about myself? I need to sort of view this page, and we have a means to sort of like not track what these people are doing.
So what I was asking basically is any standard similar to that being developed to let technology know. Are you aware of any subset?
Danielle: Not that I'm aware of because of the privacy perspective.
Greg: Fair enough, I’ll let others speak.
Danielle: I'm gonna go left to right.. Akhil, I think you had a question
Akhil: I did have a quick one just so thanks for that. It's good, just a quick one on compliance.
As you mentioned, really good, you can never be accessibly compliant for this type of thing. But I guess… I'm not going to preach it because this is your specialty, but I guess there's two parts to this. There’s structural accessibility, but then there's also content. So even if we deliver a product, we can't guarantee that the content that the client may produce or load on there is compliant, right?
Cause that's another aspect, so just so everyone’s aware, there's multiple levels. We can only do the bit that we can do. I guess in this case, we’re talking about structural and other things around the site and what we developed on our side. But then there's obviously the content itself, and that's something we have to work with the client and I would say that's a different aspect. Just atonote that I guess…
Danielle: Well, that's a really good point, Akhil. I think between the presentation that Phillipa and I did about three weeks ago and then the accessibility starter kit also has some information about how to write for accessibility for the web is also something that we can at least handle clients. I know it's really hard to do training and everything else on top of what we're doing, but at least that's another resource.
Alright, great, Roman, I think you're next on my list.
Roman: Thank you. Great presentation, by the way. I had a few questions but I will just ask one and I'll be technical. So how do we actually estimate this, right, when we pitch a project? I know I get asked a question like, hey how, how much time do you think this will take? And it sounds like we need to bake in accessibility into that estimation, I would have no idea how to do that, right? So what's the process there?
Danielle: Yeah, so this is something that, and Alfred and Paul and I've had this conversation too and why Angela has now started to get into this process as well in terms of us looking at more QA and accessibility analysts etc, is that we're trying to get it so that most, if not all of our projects, have somebody for accessibility who's there to help support you all to be able to determine how much work goes into that.
Because after we have done that, then the team starts to learn about how long it takes, and even writing the acceptance criteria and the solution direction and all of those pieces that we can start to reuse and really help get everybody to understand, not just the estimates, but what the actual solutions and implementations are.
I don't know if that helps. I mean, if there is something, Roman, where you don't have somebody on your project, that doesn't mean that you can't reach out to me and John on that though, so know that we're still a resource even if we're not dedicated. Alright, great, Angela.
Angela: Thanks Danielle. This was music to my ears, given you know my 26 years in disability, mental health and age care.
3rd of December is International Day of People with Disabilities. Is there a way or is there any intention to share this on a blog post or share with the digital community and raise awareness around this particular day?
I mean, I know that we should be including this every day in our work, but I think that there's some contribution that we should be making acknowledging the 3rd of December. Has there been any consideration there?
Danielle: So I will say I’m sad to admit I was not aware of that, so I'm happy that you brought that up to me. And, again, goes into our theme of always learning. So, yes, we do generally try to have insights written for these. I think, given that it's coming up December 3rd, that means that that needs to happen sooner rather than later.
But I'd love to talk to you offline about other things, maybe, that we could do as well to make sure that we're driving this and really appreciate bringing that up so, thank you. Alright, MJ.
MJ: Hey, um, I know in prior gigs, it was the UX lead that would always have their eye out on accessibility and there are also tools that we can use where we get scored for accessibility as well too.
I suppose from that, how do we all become accessibility champions? That's one, right? It’s because we weren't always having the luxury of having a UX lead to be a little guardian angel, whispering to us that, “hey, you need to change this or do that to get a high accessibility score,” but then also maybe using accessibility tools during testing in a sprint just to check if you finish building a particular page what your accessibility score is.
And thirdly, lastly, I think it's got to do with the comment I made earlier today. Accessibility should be treated a lot like security. It should be thought through, so it runs in parallel through the whole end to end cycle of product development.
Danielle: So MJ, I'm actually going to comment on the last thing that you said first and then I'll kind of work backwards.
So in terms of security, you're right, because if we found something that was not working for security or that we knew that there, that would be exploited, we wouldn't be like “it's fine. We could just have it, an issue with our entire site just having lots of holes in it and somebody explaining it. It's fine, right?”
We would never do that, and so, to your point, it's like going at it from the very beginning, but also thinking about what we are able to release versus not.
In terms of the testing, so there's a few different things that happen generally. It was me previously. Now it's John. Hopefully, additional people to your point, right? We are trying to do some more training as well, but either incorporating so there's CLI tools like pa11y that we can have as part of development that run.
We can have tools like ANDI or WAVE or other things that we can do during testing as well, but it's making sure that we're also going beyond that too, because, and the percentage always changes based off of who you talk too, but a lot of times those automated testing tools cover about 25% of the issues and not the remaining 75%.
And so while it's good to at least have something, it's also trying to make sure that we go beyond that. But to your point. Making sure that we have people that know how to do this, because John or I might not always be available. And to your point. It's really trying to make sure that we have people across the company that are able to do this and who are learning. And that's really the goal of what we're trying to do. Alright Alfred, it's all you.
Alfred: Those that want to drop off can drop off. I gotta lot to say, need to, but if you want to stick around. So I've got eight or nine key points I wanna sort of open up with.
Firstly, just to acknowledge you, Danielle, obviously this presentation. Your heart and soul, your passion about this area and you bringing this to Salsa uplifts Salsa and what we aspire to, where we want to get to, which is great. It's really awesome. So I want to acknowledge that.
So first thing I want to say is… just to make this more real, I got a whole lot of positives and thought provokers and areas of potential… What's the word? Controversy. It’s my job.
So firstly, I want you all to know I'm actually, I've read this probably 2 times 3 times over.
What this is is the Digital Strategy for Victoria for 2021 to 2026. It’s the five year strategy for the new entity that is formed, which is Digital Victoria.
We think of it as the equivalent of the DTA, but for the Victorian state and they’ve got this big grand vision. As part of this big, grand vision, they've got three pillars and the first pillar is basically referred to as better, fairer, more accessible services.
I'm reading off my walls, actually have posters of these actually, on my walls, pretty sad and the point I want to make here though is that this is very, very real. Government, as we know, but it's front of mind, it's something they take very seriously and with good reason, for all good reasons that Danielle has represented and I'm not going to have to repeat.
But I just want to make that point just to open up with that it's part of government’s… mandate might be strong, but certainly their strategy to ensure inclusion. Sorry, more accessible services, which actually ties to a point that's been raised in this conversation.
And Greg made a few points which is in and they talk about as well in the document. And I think it's really important for us to understand and it comes to an actual, an action, that I think we should do here is that accessibility is not just limited to, and I know we've already said this and acknowledge this, but not just limited to people with disability.
And accessibility, as per the strategy, at least, that's opened my mind and helped educate me more around inclusion also considers people in region with poor connectivity issues as an example, right?
Obviously we've already talked about people with English not as their first language, but also people with low levels of literacy, which is around content. I'm sure it's more than that. There might be others that we are not aware of, I'm not aware of, that in terms of what the definition, excuse me, the definition of inclusion is.
And so just a sort of recognise for all of us that when we talk about accessibility and when we're educating, informing, and thinking about accessibility, that it's the definition of inclusion is a broader scope.
And the other thing I want to say is that it does also, and this is the point actually should have opened up with around Salsa’s vision. Now we talk about our vision for helping governments become more open, more connected, and more consolidated. We talk about pillar number two. I’m going to use their words. I never thought about them before as being separate pillars, but hey, I'm gonna (inaudible) this, but pillar two more connected.
So part of the different... part of the… there's two key sub themes under helping governments be more connected and one is of course helping connect governments with each other, but the other big one is around helping governments better connect with citizens with better experiences, with more inclusive experiences. And we've never really defined at that level of granularity, but I think it's fair to reasonably assume it shouldn't. Why shouldn't it? Right if we want to be genuine and true to our vision that extending that to better connecting government with citizens is (inaudible).
So the fourth thing I want to say is around that this is goes to exactly what you are now doing, Danielle, for us and we as a company. We, Salsa, have the responsibility to educate ourselves, and our customers around, obviously, inclusion and accessibility.
And that starts with us investing in learning in ourselves that starts with us having these type of sessions, but there's so much more to it before that's required for us to be able to authentically, genuinely, and with authority, educate our customers to ultimately, and this could be the controversial bit, to ultimately help the customer make an informed decision.
What we can't do, ever, and I feel strongly about that, is force anything upon a customer around that, we talk about, I know the thing with this, and this is the controversial bit, but I want to be super pragmatic and real about this, which we talk about accessibility not being a feature.
But if we think about definition of accessibility. And it includes many different things around, not just people with disability or people in regions with poor connectivity, low level of literacy, English. There's a lot of decisions and a lot of things that need to be done as part of a project for the government to make an informed decision on which of these definitions or which of these areas that they want to address, right?
I think that's super important and our job, and this is where I want to make it, our job is to educate, but I want to take it a step further, is not only to educate, to say and build it into our process, build it into the presale, building to the discovery, absolutely, that makes us part of what we need to do to uplift, but also I'd like to think and say, and we're trying to do that with CivicTheme, we're not there yet, is and that's just one little bit, but and it's not even about tooling.
To build trust and innovate, build good processes, good templates, good tools upfront to lower the barrier to make it easier and cheaper and not this much more expensive is what we've, some of the theories are to make it easier for them to have.
I don’t use this word and I'm sorry to use it. 'cause I'm now being super sensitive, which I don't want to be, by the way, but just to ensure that they are being all inclusive, right? And the more we can educate but also innovate through building our backlog in our repository and our…
Con referred to a word about a year or two ago, can’t remember, but basically our assets and our IP. I don't mean it in a proprietary sense, but all the collateral that we built to make it easier for our customers to be more inclusive and lower the barrier to make it easy for them. I think that's a responsibility that we have.
Yes, the other bit around the WCAG guidelines. I... yeah, it's interesting because it's a point of reference and it shouldn't be, based on a tickbox exercise, absolutely not.
It has to be very real, but we also need to bring the customer in on the journey and given that choice about “hey, that's one thing about saying we can based through our knowledge, work through these guidelines and then there is a point of reference, but it's so much more than that and give them the choice is so here's you have one ultimate validation. It looks like XY and Z and there is… this is the implication of that in terms of cost and time.” And then, again, they make an informed decision.
And finally, what I want to say, just to wrap all this up. What I actually think as we talked about next steps and what do we do? And Danielle has given some tips on where to go and read materials, and x, y, and z.
I actually think that it's a good exercise if the accessibility team and our Ops Lead come together to build a backlog. I'm not saying we're going to solve all this, but once we build this backlog, what are the tangible tools, processes, playbooks that we can integrate into Salsa process so that we are getting better and lowering that barrier to make it more and more inclusive?
And so I would say a good action to close the loop out of this and to avoid that we do this presentation, we go away and we, something more tangible, is to do a few workshops to build a backlog of and then put some priority in resourcing on to slowly chip away. Slowly, not all at once, but just adopting lean agile principles. So yeah, that's all my thoughts. It’s a lot there. Thanks for listening.
Danielle: May I respond for 30 seconds?
So Antoine and I have already had a conversation. Part of it was about going to some of the EM alignments, but, to your point, having some of those discussions first.
In terms of accessibility, this is where kind of that piece gets a little mixed as to what is accessibility versus what is inclusivity, but I think Alfred to your and also Greg's point, I mean, but it's important that if we look at the DTA standards, I feel like they have a reall,y really good list and explanation right as to what is accessibility somewhat versus what is inclusivity, again, according to Australia.
Because Greg, I'd be interested to talk to you. If I said, “hey, here's kind of what Australia says from the DTA standards, what do you think like from your experience and what you're hearing?”
Another piece, yes, absolutely. We're not going to force clients into anything. Totally agree. I think in terms of, and it's a good point to clarify, I think with WCAG and not necessarily meaning that that's a compliant site. When I look at that, it's really more about the user centred design and human centred design, cause a lot of times when we do those studies and we do that research, it's mostly with people without disabilities.
We don't bring people with disabilities into the process. Same thing with usability testing, and so that's really how we start to do it. So if we are doing UCD and HCD, or if we are doing, also usability testing 'cause a lot of times they can be looked at as two different things, then people without disabilities should also be included in that.
Sorry Akhil, I think you had something you want to add.
Akhil: Yeah, just a couple of points to what Alfred was saying.
So, in terms of our audience, but there's two points. Our audience being mainly government, it's actually legislation for government agencies to actually abide by the Disability Discrimination Act in 1992.
Some of the Disability Discrimination Act is that government agencies are required to ensure information and services are provided in nondiscriminatory accessible manner. That is partly why they are so strong on it, because it's actually law.
So what level they do that kind of varies, and there's some kind of loopholes of, yes, we're getting to that certain point, but that's why it's in there. It's actually built into it.
And then the second point about costs and in factoring it in. Well, this is a similar conversation that was... there shouldn't be, but it kind of was that idea of responsive design. Yeah, it's very expensive, we should make the mobile that's not just build into the design, right?
So accessibility should be built from the beginning ,and there's not an additional cost. If it's built from the very beginning in the foundations of everything we do, well, all developers, everyone involved. If they know the information that we are now learning then it's not really an extra thing, it's just part of the process.
Danielle: Alfred, thank you for all of your points. Sorry I didn't need to be like, I need to respond to, just I know we’re over so.
Alfred: No, all good. All good.
Danielle: Ok, alright, well, thank you everyone so much. I really appreciate it. And, obviously, if you have any questions or want to have any additional discussions, please let me know.
Like I said, those coming soon hopefully are coming very soon by the time everybody's back from break at the end of December. Early January will definitely get more of these processes in place, but this is where it starts. So, hope everyone has a good rest of the day. And sure we will talk soon. So thank you
