 My presentation is going to be on the Moodle Collaborative Accessibility Group. You guys have, you heard the presentation about the other working groups that are here. This group's a little bit different. First, I want to introduce myself. I'm Jason Harden. I'm the senior product manager at Moodle Rooms. My job really is to work with the community within Moodle Rooms and help make sure that we're helping contribute to the community in positive ways. This is the agenda. Pretty quick stuff. I'm pretty sure you can read it faster than I can talk at this point in time. So the background of the group, we were founded in 2013 by these institutions, Moodle being Moodle HQ at the very bottom. The reason the group was formed and the reason it was formed kind of outside of a moot situation was because one of the members received a Department of Education complaint by a student on their campus that specifically named the Moodle forums as being inaccessible and discriminating towards that student and as the vendor for that client, we wanted to make sure that they continue to use Moodle and continue to host with us. And so we wanted to provide them with an option that really worked to meet those users' needs on their campus. Ourselves as well as that campus, which was the University of Montana, not only took it on our poor selves to solve that problem, but really to think about it and push it in a very positive direction. So they made a significant amount of changes on their campus to become excessively focused or excessively born, which is a topic I'll cover a little bit later. We as a vendor took it upon ourselves to say how can we engage with the Moodle community to really improve the accessibility overall within Moodle. And the other thing that we realized relatively quickly after we started our project on improving the forums was this wasn't going to be where this ends. We needed to work as a community to train all of the developers within the Moodle community about how to think about excessively born. And that's not a small project and it's not something that a vendor can do. It's not something that a single client can do. It's something that the entire community has to rally behind and say, this is something we want to work on. As a group, we're structured relatively loosely at this point in time, very similar to the grade book working group. We are moving to become international as a group. So we want to be region based. So each of the different regions, what we found is we started out with, OK, we want to have meetings once a month. We want to include anybody and everybody in the world who wants to attend. So we had members from the UK, we had members from Australia, from HQ. We had four different time zones in the US that we had to deal with. And what we ended up finding out is everybody who was really passionate about this project was getting up at all hours. Some people it was six a.m. Some people it was midnight. Some people would actually feel kind of sorted during working hours. But it was really something very difficult for a lot of people to participate on a regular basis. And so we were seeing attendance drop and drop during the meetings. And so we decided this year to move to a region based system where as individuals in regions said, I want to do I want to make our own region. I want to make a group that talks about this topic similar to how the working groups are working now within the Moots. There's the regional groups in Australia for the Australian Moot. There's a group here in the US. There was a group in the UK. We wanted to do something similar. We also wanted to coordinate as a group so that when we said there was a problem one group could talk to the other and they could continue to test. The reason for the regions to also is because certain regions have different requirements for accessibility and maybe using different technology that is important specifically to that region. They may also be using different tools within Moodle that are more important than other tools based on their educational system. We meet once a month virtually right now within North America. We're also loosely based from a leadership perspective. So technically I lead the North American contingent. I would gladly step down if there's somebody else who wants to work on it, who's more passionate about it, who maybe has some more time to dedicate to it. So that's really those three pieces are what makes a leader within this organization or this group. It's your passion for accessibility. It's your ability to be active and then your commitment to this group. So just to be able to be committed and it changes. Before me, there was a leader was Greg Kraus from North Carolina State and he has since moved on to another position. So his commitment to this project has moved on because he's now dedicated to a much broader focus for accessibility. So this year we're looking at expanding. So we've got interest. So the orange area is North America. That's where we have a very strong contingent. We have some participation in the UK. We have interest in both Brazil as well as Israel in creating regional groups. Brazil has its own unique set of issues. A, they don't speak English, which is different. But B, they also use a product very commonly called DOSFOX, which is not something most of the first world countries are actually using. It's not something they would consider. And I'll talk a little bit about some of the things that we're focusing on from a Moodle perspective around technology. But this is something that came up as new because we had a member who was using Moodle in Brazil who said, hey, look, this is a problem we're having for accessibility. We also have interest in Australia. There's multiple universities in Australia looking to help out with this group as well. So what's the group's goals? When we initially formed, we formed a very long term goal and that is to make Moodle accessibly born. Or born accessible. Born accessible means that when a programmer is developing a feature or functionality, they are thinking about accessibility during that process. It's not something where I create a feature and then as testing starts, now we start testing for accessibility. It's something we're thinking about when I make that form button, when I make that form. I'm thinking how would somebody with a screen reader interact with this? And then when we get to QA, we're QA'ing that and we aren't saying, oh, well, we found six accessibility bugs because you didn't think about X, Y, or Z. That's where accessible born comes from. It's also accessibility baked into the design. So when you're thinking about your front-end interface, you're talking to users with disabilities and saying, how would you use this? And what ends up happening is as soon as you start talking to somebody with a disability, you start thinking about how they see the world. And what you realize is they really don't see the world that much different from a sighted user. In fact, information you provide specifically for a disability initially actually generally has a benefit for somebody who's visually sighted. And so that comes into play when you reorder things because the order didn't make sense to a screen reader user. Or that comes into play when you say, I need a more descriptive text because when it's read out on the screen, it makes no sense because the context isn't there. That actually benefits clients as well. We've had internal conversations about analytics and we said, how would we describe really complex information to somebody with a screen reader? And we said, well, we could look at highlights. And then we realized right after saying that, that's going to benefit a teacher who might not be a data scientist who might not understand this really complex visualization. Giving those highlights initially came from how could we describe this stuff to somebody who was blind but then provides benefits to somebody who has sight as well. We also want to focus on creating prototypes. So initiating conversations about it, creating designs and prototypes that can be played with because the reality is even though you say somebody has a disability, there are a lot of different disabilities out there. And what might be a solution for somebody with a screen reader may not work as a solution for somebody who navigates the web with, say, a foot pedal. And so having conversations with both of those types of users makes sure that when you design, you're designing it to meet all of their needs. And then lastly, we want to be able to test accessibility at every stage of the process of development. So not just at the beginning or at the end, but we want it to be included while we're going through the process. Our short-term goal is because we realize that is a very daunting task. That is something where you have to educate a lot of different people around accessibility, what are good practices, what are bad practices. We want it to also focus on the short-term. How can we impact Moodle now? And the way we've decided to impact Moodle now is first identify issues that exist. Then we've found that the best way to help somebody understand an issue, especially when it comes to a screen reader user or somebody using a foot pedal or another disability is to show it to them. Lots and lots of tickets in the Moodle tracker have a lot of text on how do I test all this? If you don't understand how to use a screen reader as well as a user with a disability, then you may not see the problem or you may not be able to execute the test steps in a way that makes you understand the problem. And so demonstration via video generally is a huge benefit for both the user who's testing it, but also then the developer later on who needs to understand how can I fix this. We're also working with Moodle HQ to prioritize those issues. So there are a lot of issues in the Moodle tracker that are identified as accessibility issues and they range from minor to critical bugs. We need to validate A that a lot of those bugs still exist in Moodle and then we need to make sure that they're of a priority that the accessibility community or the disabled community agrees with. Next we want to help test. We want to make sure that we are providing resources that can help Moodle test interfaces that are existing again going back to that regional based system where in my region if quiz is really, really important to our pedagogical needs, that's what our region wants to test and make sure is accessible. We're also working to prototype. As we have institutions with develop with resources for product development, like myself within our organization or other institutions who have joined, we want to create prototypes and the idea there is to show examples to other developers of this is an accessible interface. So we've done this with the advanced forums which was the initiation of the group. We've released it to the Moodle community and said this is an example of an accessible forum. It may not be how the core developers want to create an accessible forum within Moodle, but it is at least a stepping stone that we can say look at this and then get ideas from it and decide how you want to go forward. And then finally we're creating alternatives. Advanced forums is an example of an alternative. It's something that has been out in the community for several years now. It is probably the most accessible forum out there, but it is something that if you're concerned about it, you can install on your Moodle instance and run for a period of time until you're okay with wherever the other forums are at. So it's an option for you as an alternative until we get things up to the level we want them to be at. So next I want to kind of talk about some of the accessibility policies that have come from discussions with Moodle HQ. First, Moodle has said they're going to be WCAG to double A compliant in all of their interfaces. That's very critical, especially since WCAG is more internationally known and accepted than say 508 compliance. The next piece of that is that you may have noticed, I think it was about 2.6, there was a setting removed for a user that could say I am a screen reader user or I have a disability. That was removed because Moodle made the decision that they are going to make all of their interfaces WCAG to compliant and accessible. So if there's drag and drop, I'm going to have that capability, something that a screen reader user can use instead of creating alternative interfaces just for a screen reader, which is very important from a screen reader user's perspective because if I'm as a company dedicating all of my resources to create this one interface and then I have this other one that I'll kind of pay attention to every now and then, that's not really okay. That's not how you want to feel as a user. But if I know that if I say this interface that you've created has a problem for me and you're going to say, well, we're going to make that work, that's actually a very positive message to that community. The other thing that I wanted to say is these are the different interfaces that we've said we're going to test with. And because there are a multitude of different assistive technologies out there, we had to narrow it down because Moodle HQ only has a limited amount of resources. It's a reality in this world. And so what we've picked is Windows with Internet Explorer and JAWS, which is one of the most common setups for a user with a disability. And then Windows with Firefox and NVADA is another option for those who might not have the money to spend on JAWS because JAWS costs about $1,000 a license. It's a very good alternative. And we want to make sure Moodle works with that as well. And then for those who are using Mac, it's going to be Safari and VoiceOver because NVDA and JAWS don't work on Mac at this point in time. And then for those who don't know, from a mobile perspective, iOS is one. It's the number one interface. It's roughly about 90 for 5% of disabled users that use mobile devices, which there are a lot that use them. iOS has the most accessible interface. Android is slowly getting there, but Apple has been very good about making an interface that is usable for a user with disability. So we want to make sure we test the mobile responsive interfaces with iOS, Safari, and VoiceOver. Martin mentioned in the keynote that Aaron, who is one of the members of this group, tested the Moodle mobile application on iOS with VoiceOver and his device. I also kind of want to talk about managing issues. It's really important to us that when we create an issue about a topic, we have a set structure that is followed in order to make sure that the developers are getting all the information they need. So I get back to the regional groups. They determine their tests. They determine how they want to test the software because it's going to be based on how they're interacting, their pedagogy, with the Moodle instance. Issues are always reported to the Moodle tracker. That has been consistently set as where issues should be reported. When we report an issue, we document what the issue is in the best text that we can describe it as. We work to state the WCAG-2 conformance that it does not meet. And then if possible, we actually link to that document. That, again, is to help a developer understand what is it I'm supposed to be doing. And then oftentimes those compliance pages will give suggestions on how to resolve the issue as well. We also post a video. We've post those videos to YouTube and then link them to the ticket. And I'll actually show you a video in a second of a test that Aaron has done. And then finally, we add any accessibility components so that we can track what accessibility tickets are out there. And then we add a label for MCAG. And that identifies to the Moodle core developers that this has been validated by the accessibility community as an issue of importance. So an example of this would be, if you go to the Tracker MDL47095, and I have this linked here, this is an example of that ticket. And so you can see up at the top under Component, we have it filed as accessibility. It happens to be a file picker as well. Under the labels, we have MCAG. We have a bunch of other stuff just because I like to tag things as important, because as a partner, I get to do that. It's one of my fun joys in life. But then we also have the description and the testing steps as well. And in here, you can see also the YouTube link to the video. And I'm going to go out here. And this is the actual video for that. This is a demonstration video, an issue that was found with the Moodle file picker in which it may be unclear to a screen reader user as to which repository it is that they're currently looking at. To demonstrate precision, I'll begin by going ahead and opening up the file picker. And I'll allow my screen reader to just go ahead and read the window like it normally does. Extend all channels for content at dot com space. File picker. File picker calls dialog. File picker dialog. No files available. No files available. OK, so we're at the file picker dialog. We're at the file and I'll close the dialog and then announce that there are no files currently available. So nowhere in there did it tell me the name of the repository that's currently being displayed. Next, I'm going to go up to the top of the file picker dialog. And now I'll begin to error through it and you'll see if you can find where the repository is listed there. List of six items. Link server files. Link license files. Link upload file. Link URL download. Link client files. Link the Dunedia. List end. So right there was the list of all the different repositories that are available. But by streaming we didn't read any of them that made marks checked or selected so that there's no indication there is to which repository is in current name. So I'll stop it there. But that's the idea. That's the amount of information that we really want to give to the developers. We want to show where it is I am in the system so that as a sighted user I can understand as a developer where I am. But then we also want to make sure that you're understanding what's going on within the screen reader. What am I hearing? What am I understanding from what I'm hearing? And where am I missing things? We also recommend testing with both a sighted user in the room as well as somebody with a screen reader. And the benefit there is that the sighted user can see where they are on the page, can identify what they might be missing while they're listening to the recording within the screen reader. We've actually found that this has been very beneficial for a lot of the work that we've done within Moodle Rooms to then also have a developer or a user experience designer on the other end. We've done it virtually via Skype to have the two people in the room doing the test and then have somebody on the other side who's going to end up fixing it listening and then asking questions. So that's another step further. So what are the top 10 areas in Moodle that the group has found need some work? To start, Moodles. And these are actually ranked based on the priority that the group saw. And that starts with the learner and the ones that impact all users across the board. And then we slowly get down to those that impact instructors. The reality is is you're gonna probably have more learners who have disabilities than you are gonna have teachers. That's not to say they're any less important but the priority is to make sure that the students can get the information that they want and need to get through their education to start. So Moodles have the issue that you get locked out of them. You can actually, so a Moodle will pop up. You can tab through it with the screen reader and then somehow you can actually get to the content behind it. And that's a problem. And that impacts every single Moodle in Moodle. And so that's where we start our conversation because Moodles are very important within Moodle. The next one is the expand collapse state of Moodle. So the navigation block, the administration block, it's used lots of other places as well. The reality is that a screen reader is not told when they expand a menu that there's more content in that menu. And so they can't understand how to navigate. It's pretty critical when your navigation block depends upon that. And so the student to be able to navigate through information needs to use that block. File picker is another important one. You saw that ticket up there. He couldn't understand really where he was. He can use it, he can figure it out because he's been a Moodle user for a while, but a beginning user needs more instruction, needs to understand what's not being said. And that's a problem. That isn't something that we should have in the system. You'll notice that none of these are really showstoppers. They're important issues, but it's not like somebody with a disability can't necessarily get through it and figure out how they want to deal with the system. So that's a huge positive for Moodle. It's generally accessible. It has a few issues here and there. The next one is consistent heading structures for all pages. So in the course page, I have a consistent heading structure. I have an H1, I have an H2, and then from there it goes H3 and down. Heading structures is how users with disabilities, specifically with screen readers, navigate most pages. They find the heading structure and they figure out where they can jump through. So they can jump to pieces of information on the page really, really quickly. The other way they do that is also with links on the page. And so the idea there is when I'm in an activity, when I'm a couple pages into an activity, that heading structure needs to stay. I need to still see that heading one that likely goes back to my course and I need to be able to understand where the heading two is. What ends up happening is on certain pages, the heading one shows up, but then the next thing down is a heading three or a heading four, depending upon what the instructor's doing from content perspective. And so that inconsistency causes confusion for a screen reader user. Forums unfortunately are still inaccessible, inaccessible I would say. We're documenting that, but reality is there for a user with a screen reader, they just can't understand the structure of the document. They don't understand the conversation. They don't feel like they can be a part of that conversation. And it's something that is very concerning. The reason why it's the fifth one down here is because there's an accessible alternative. Advanced Forums is out there and that can be used by community members if they want to. So there's an option. Everything else, there's no alternative at this point in time. And so it's a much higher priority. Now we kind of get into some of the topics that are a little bit more difficult to actually implement solutions for. Math equations is one, that actually works really well now in Moodle. There is the ability for the first time ever for a user only with JAWS and Internet Explorer, and if you're using the math jacks filter to actually have a screen reader read out a math equation, which if you've never heard how difficult that is before, it's saddening. Aaron Page, who was a member of this group, had to switch majors because his original major, Computer Science, required a lot of math courses. This feature didn't exist in Moodle or anywhere on the web at the time. And he was unable or it was extremely difficult for him to actually understand math equations, specifically on tests, as well as within books that he was reading. And so to go from that to all of a sudden I have access to that information at my fingertips is a huge benefit for somebody in that situation. Well, we need to be able to do more. We need to push beyond just those two setups and figure out how do we display complex information to a user with a screen reader? So all of those things we talked about with learning analytics, how would somebody with a screen reader understand that? Are there other areas within Moodle where mathematical information is displayed that needs to be easily understandable? Complex ideas are essentially the wild, wild west or the next frontier from an accessibility perspective. How do you create information that can be understood by somebody with a screen reader when it's extremely complex is where they're beginning to push. Videos in Moodle is another huge area. I would guess most of you in here, if you want an accessible video, you probably put it up on YouTube or Vineo. And the reason for that is because Moodle doesn't have the capability for you to add captioning. You can't add alternative tracks. There's a lot of accessible information that should be provided within a video that you just can't enter in. It's not that you don't necessarily have it or want to. It's that the interface right now doesn't allow it. Course management is another difficult area for an instructor with a disability. Being able to figure out how to turn editing on and what that actually does to the course page is practically impossible for a screen reader user. When I turn editing on, I don't realize that there are a whole bunch of icons that just appeared or menus that are there now that I now should be accessing in order to edit information. Rubrics and Marking Guide, another, again, not a hugely used feature, but it's one big table, if I recall correctly, without very well-structured headings. And I click a button and all of a sudden a new row has been added. There's no information about what happens there. So that's another concerning area from accessibility perspective. The last one is actually the most interesting to me because it's more about making sure Moodle doesn't allow an instructor to put inaccessible content up there. So you all might have looked at ADDO and you may have noticed that there are a few areas of ADDO missing. There's no ability to change the font type. There's no ability to change the font size. You can add headers. You can say heading three, four, five. They're marked as small, medium, and large text. There's no way to add color. And the reason is because none of those pieces of information actually convey anything to a screen reader user and they can potentially be used to create content that a user with low vision can't understand or can't read. So for example, if I change my font from a serif font, which scales very, very well when I zoom in and zoom out to a non-serif font, all of a sudden somebody using a zoom mechanism on their desktop, the text starts to pixelate and they can no longer read those letters anymore. Or if I use a font that's too big or too small, I can't understand that information. So it was a conscious decision to say, we want to limit the ability for teachers to create inaccessible content within their course. File uploads are a place where we don't have that. We don't have any capability to say, did this instructor upload something that doesn't meet WCAG guidelines? Does it have heading structure? Does it have information that a screen reader would use to actually process through it? I mean, ultimately my recommendation here is we push teachers to not upload files, but I mean, anybody who's been teaching in the education industry realizes that's a far fetched dream at this point in time. So those are the top 10 areas that we really want to focus on and are actively working with Moodle HQ to figure out solutions for. We'd like your help. So this URL here is how you get involved. You'll notice this sadly isn't, well, if you went here, you would notice this isn't a Moodle HQ course. The problem there is because their forums aren't accessible, the users with disabilities don't feel like they can be part of the conversation around accessibility. So we've had to use a separate site which is fully accessible to those users. We have meetings, as I said, once a month. Next one coming up is August 17th. That's gonna be for the North American contingent. We're still getting the Brazil, Israel, and Australia group to decide when they wanna actually meet. And this is the calling information. If you go to that URL, this teleconference will be all up there and you'll have that information. Any questions? I think I might have about five minutes. Oh, nope, I'm actually over time. Where is? One minute over. Dan, go ahead, real quick. So for an observation, a lot of those illicit accessibility issues, a lot of them are actually things that meets the fixed, the mobile as well, like no need to go into a telegram or mobile. I mean, could you kind of work on that? Yeah, I would definitely agree with that. One of the conversations we'd love to have is around the pattern library. And can we actually make the patterns in a pattern library accessible so that when a developer just uses a modal, they know it's gonna be accessible because we've made sure it is from the get-go. Right. All of these things are... Yep, so that is, don't mean to make this presentation seem like doom and gloom. The Moodle HQ, they have been a member in this. They have been extremely responsive here. This is not something that they've just said they've ignored. We've been working with them on this for two years and we've seen significant progress. ADO is an excellent example of that. So thank you very much.