Hello, everyone I'm Marisol Miranda from the EASI equal access to software and information and I want to welcome you all to this webinar on Sakai accessibility. I want to say hi to Ryan Richwine and Mary Stores who are the presenters today and now I'm going to turn the mic over to Norm Coombs. Hi, Norm.

   Hi Marisol, hi, everybody. Glad to have you here today. To remind you, the recordings will be online at the same place. Marisol can type it into the text chat, but it is EASIsite.cc/archives/LMS/resources.htm. So if you go there you will find the recordings from last week, the slides from last week, transcription from last week and probably by Wednesday or Thursday we will have this recording up there in the archives as well. So we are doing a series looking at different learning management systems and we picked some of the ones that I hear the most about. There are some others and some others come and go. Angel can be fairly popular but that's going to be morphing into black Ford as is Web CT. So what we are doing is looking at Moodle which we did last week, Sakai, which we are doing this week and next week we are doing desire to learn and last week will be blackboard. Checking calendars that looks like the US will be staying on daylight savings time for up through November 7. So, the last webinar which will be Tuesday, November 9 on blackboard will be on standard time, will be on daylight time up till then, then we will switch to standard. Keep that in mind and I will send out reminders to that effect. Thankfully I've never looked at Sakai and I've never worked with Sakai I'm looking forward to the presentation because I'm going to learn a lot too so I'm going to sit back and listen to my two guests, Brian Richwine and Mary stores. Take it away, guys.

Thanks so much, Norm and we appreciate that you put this series together and we appreciate being involved (inaudible)  As Norm said this is Brian Richwine I'm from Indiana University and we, Mary stores and I work at the adaptive technology and accessibility centers of Indiana University. And we both have worked here for about 10 years and are active in supporting students, faculty and staff with accessibility. I am the senior tech administrator for the center as well as the web accessibility team and I will let Mary introduced herself.

I am that the alternative format (inaudible)  at the APEC and I'm a member of the product stability team here.

I've got a lot of slides and in the first of so many sides kind of talk about Sakai and I'm going to talk about those fairly quickly and when we get to the bottom half of the slides where it starts to talk about accessibility we will be going through those slides a little bit more detailed. So if there is information on the slides I know that some of them are pretty heavy with text and I go through some of them fairly quickly then you can go back to the resources and see them again. So here is the first slide that's basically talking about the adaptive technology Center. We support students with disabilities as well as faculty and staff at Indiana views diversity and also off-site and university campuses as well so we've got a lot of experience converting materials, versus alternative content, working with students who have to access the content and i.e. whether it be that learning management systems that I or any of the other systems. And anything else it takes to get them there. So Sakai started as a product back in 2004. And it is a community source software. A bunch of universities got together and decided to work toward a common goal and merge all of their energies. Also, the new portal Consortium and the open knowledge initiative groups that were talking about information exchange and whatnot. Today's Sakai is used by over 350 colleges universities and schools. If the universe is international project has a lot of international pacing feature is used in 35 countries. And as Sakai is distributed, it is open source software. We use the educational community license which is called an open open license. Basically it's pretty unrestricted. You can take the code and use it for commercial or noncommercial reasons. They don't pose any particular license on any derivative works so if you take part of it, modify it then you can take a run off and use part of that for-profit if you want. It supports the development of Sakai, we started the Sakai foundation which is a not-for-profit organization that basically (inaudible)  staff to try to put some continuity together between all the people who are working to develop Sakai. So that has already been a director, some people who make sure they are walking for the quality of the product. There is a product Council that is selected and people on the council decide which features sexually go into the main product so it is not just a scattershot group of people developing it. There's actually some organization trying to keep the product going in a certain direction and making sure that it's coherent and has a pretty high quality to it. As such, as an open source there's a lot of people working on developing Sakai. A lot of educators at different universities get together a lot of the developers of Sakai come from the same universities so that developers designers and educators worked pretty closely together and usually university adopts a certain tool or feature of Sakai and we work with the community at large but also with the schools to set up the requirements that go through and make sure that each feature actually needs the real academic need and does a good job of supporting the academic community. There's a lot of e-mails and wiki pages and weekly and biweekly phone conferences that people get together we also have several different Angel conferences that people can go to where everybody gets together and enters the network all at once. Some more information about Sakai, there's a Sakai project.org website and from there you can figure out (inaudible)  anyone in the University with the founding memory Indiana University was a founding member of Sakai and currently very active in the development of Sakai. Andy and Indiana University we call the presentation, or set is used literally by over 100,000 university students in 10,000 faculty members across all of our campuses. So it's a very high demand, it has to be up over time and a lot of people are using it. It's probably one of the most critical resources we have got supports Indiana's mission. Before Sakai came along Indiana University have a lot of locally developed computer systems that sort of served university well and they could change the most anything but IE was alone in designing those in being responsible for maintaining them, paying for the cost of that. So the benefit of having a large open source project like Sakai is that it allows you to maintain flexibility in making changes in the code and using it in a kind of specialized way for their own campus but also allows for the maintenance and upgrade cost is all kind of shared amongst other universities. So I get better cost of ownership while still being able to make modifications and changes as we need to for our purposes here at Indiana University. As far as instructor support it takes a lot to get people used to using a learning management system. So if you're going to be very effective at an institution of something like Indiana University, then there really needs to be a group who is going to support that mission. So at Indiana University that falls under the teaching learning technology centers. It's another department under the University information technology services. And we work with faculty and students, anything they need to do to support the upper previous of technology and instructional settings at Indiana University. So we offer courses for instructors as well as students. We can put our documentation. We even have little videos where students can go in and how to do different things on Sakai for their own course. One of the things that the adaptive technology Center has worked with the teaching and technology centers is make sure they include technology centers in their training. We've given some handouts for instance on how to create successful accessible Word documents and accessible PDF and I talk about that briefly when they are talking to their faculty and the big things they stress or any of the contents that they create that gets plugged into Sakai or even if they give it out in the class. They need to be accessible and should have headings and whatnot to be easily navigated. Our overview of what Sakai has. Of course it is a learning management system. As such you can create within it cites for courses, funny special academic course at Indiana University can have its own site and then you can also create project sites. So if they are working on a particular project or research something we can create a project site within Sakai and store all of our information to communicate back and forth setup time whatnot, any kind of collaboration that we want to. Students also get a space of their own and they can create project sites. So anybody who logs into Sakai automatically get something called my workspace. When they login it automatically goes to that site and goes to the home page. That allows students or anybody logging in to have a place that they can store documents of their own. There is a calendar where they can manage your store appointments. If they are a student at Indiana University it automatically logs the course scheduling today are coming to the calendar so they automatically have a place they can go where the class schedule and even the final exams get plugged into the calendar so that they can schedule around for courses and tests. When you log into Sakai, there are several different navigation pieces to it. So across the top of Sakai, you will see a toolbar and it displays as tabs are the different courses that you are a member of form may be project sites as well. And it can hold about five courses. So of course if you are a student at IU used probably in the world or take it more courses than that, so there's a little dialogue that's off to the side you can click for more courses and expands into a list of all the courses that you've taken. There's also a minibar, any site that you go to has different features to it, and the creator of the site can choose and pick from a variety of features. Along the left-hand side of the screen is a minibar that lists all of the tools that are available for any particular site that you are in. And those are actually marked up as a list of links. There is some text that describes the tools, there's the syllabus, or the calendar or some announcements or the chat tool. Anything like that, those will appear on the left-hand side and as a text link as well as a graphic icon. So here is a screenshot. Perhaps those don't come across very well, not clear to see that I wanted to go ahead and include at least one graphic to give you a view of what Sakai looks like this is what Sakai looks like when you first log into and as you can see there are some three tabs at the top of the page. The heading is pretty spartan. There's not a lot of anything that people would have to navigate through.  It's got the Sakai graphic logo and the logout link, then the tabs that represent the different workspaces. So you have to workspace, my workspace that everyone gets and you can see two tabs under that represent classes that this particular user is signed up for. Then along the left-hand side you can see that there is a hotlink, profiling, membership link that is a toolbar that lists all the tools that are available. If you click on a class or one of the other worksites than the toolbar may be different depending on what tools have been configured for use in the class. This is showing the home page of Sakai. As you can see there's a message of the day, there's a little calendar display, and a section that would be displaying the announcements. This in particular, is a screenshot of the QA server of Sakai, not an actual running implementation. So there isn't any real message of the day or message on it but this is what you would see in a default installation of Sakai. Mary and I are involved in the Sakai accessibility working group.  That's how we fit into Sakai. Part of the organizational structure of the Sakai community is often that it breaks itself up into different working groups. There are working groups who deal with usability issues, there are working groups to deal with the user interface design, there are working groups for the various programmers to get involved with the Kaiser they can share information. There are working groups for different versions of Sakai, so people who do maintenance programming, people developing training documentation, people who develop user documentation, all different kinds of groups and Sakai has added accessibility working group for many years and several people have taken the lead of that. It changes over time and it's a very active experienced an engaged community. There's a lot of people who participate in it, and we have biweekly teleconference readings over the phone. We have an e-mail list that we share information over and we also have a wiki space I love it more permanent place that we can close resources for the community to look at large. One of the big things that the Sakai working group does is that it provides a place people can go to in the Sakai community where they know they can reach accessibility expertise. A lot of the more formal function is sent to provide accessibility reviews for Sakai predicament with the new version of Sakai and then there is a release schedule that comes out with that when they are deciding what features go into and then they start pulling that together. There is quality sharing space with a daughter quality assurance testing. We are included in the quality assurance testing phase and we can file bug reports basically for any accessibility issues that we find. And assign those two different people to work on and keep track of them. One of the things that we've done recently has come to the realization that we were communicating those bug reports to developers in a way that probably wasn't as effective. Sometimes it's hard to scratch another person's age, so to speak. So when we were reporting accessibility issues we were putting those into the bug tracking system and accessibility experts (inaudible)  so we were describing those they should understand what we were talking about and then we started to realize that that wasn't as effective as it could be, so that what we have done now is, we've gotten better at writing the bug reports to where we communicate the accessibility issues in terms of the program in terms that the programmers themselves understand. So we describe how the issue actually affects users, how to go in and reproduce the issues, then we provide really detailed expectations as to what we think the solution should look like. In the past we were just say quote some accessibility standard and give an example that this piece of the code violates that and expect them to be able to fix it and expect them to know the best way to fix it. So we've gotten a lot better at communicating with the developer community and part of that is the accessibility working group has been lucky to have developers actually participating in our working groups. And there are two developers regularly attending our meetings, plus we have pretty good working relationship with several other developers and often do maintenance group in the release management, a Sakai has taken accessibility pretty seriously and we've even made a quality assurance lead person just for accessibility because we realize that accessibility issues are crosscutting. They go through a lot of different sections to the tools everything is a chance of impacting accessibility and it's been great to see that they take them so seriously. One of the things that the working group did in the last year was to create an accessibility statement. So that guides the Sakai community to know what our goals are. It was passed along and vetted through the Sakai product counsel into the community at large. People provide a lot of feedback trying to figure out if this was a realistic goal, but they actually use it. We also went through and updated the testing protocols and created what we call a functional block through scripts and we will talk a little bit more about that in a few minutes. A big plus for us was that Mary and I got to attend the Sakai conference that they had back in June of 2010. We gave presentations on accessibility and gave several interactive demonstrations of Mary using a screen reader to access the Sakai. That was very well received. We actually had the schedule, schedule multiple ones and I think we pay for presentations just showing people what I would like for screen reader users to access archive. They were very interested in seeing that (inaudible) . Developers have developed some pretty good working relationships and also got to talking to them how best to communicate with them about accessibility issues and how to get accessibility into the design stages. As we mentioned before the typical role and doing accessible.tar review in the testing phase which is pretty well near the end of the design phase. So we've been working with and the Sakai community now is how we can insert herself and design phases and actually work on accessibility while the product is still forming instead of testing it into at the end. That's pretty exciting for us. Of course it's giving us a lot more work to do. So the next three sides have a lot of text and they are basically the accessibility statement that we created for Sakai. And I don't mean to read it all to you, but basically what it shows is that the Sakai community supports accessibility and the foundation backs that. They consider it important. And essentially a lot of people ask us well why isn't section 508 listed in the accessibility statement and well, 508 is being updated now, but 508 that is out there currently has been around for a long time. Literally I think over 10 years now. And a lot of sense of Sakai is an international product than section 508 doesn't apply to a lot of the countries that Sakai is used in. And we realize that the Web content accessibility guidelines put together by the W3C Web accessibility initiative 2.0 are actually referred to in a lot of international standards and legal requirements that various different countries have, but also they cover everything pretty well at 508 covers and more. So we are using a week out of 2.0 level A. and leveled the blow success criterion for Sakai as our standard to design against. The last part of the accessibility statement is basically just stating that you know, the core tools that are used in the Sakai will undergo regular document accessibility evaluations and that's basically saying that we are going to test the tools, we are going to provide documentation that we test against and the results will be published on a wiki so that everybody can see that. So, essentially what we do and accessibility review of Sakai this is for a server course of Sakai tools and what that means is that when someone gets Sakai there's a set of core tools that the product counsel has said this is what Sakai products represent. So if you were to download Sakai, the source code and actually install it and start working with it those would be the tools that you see. Of course in different individual institutions can configure those us they want, even remove certain tools so that they are not there for faculty or students to use but they can also choose from a lot of tools that are independently developed. Maybe at their own institutions or other institutions might get pulled in and a lot of times we actually go out and evaluate those tools as well as we can. Especially (inaudible)  say Indiana University, or working group has received feedback that maybe the tools have some accessibility issues. So we prioritize the Courier tools used in Sakai, we prioritize the core tools that students see the monster and the personas that the students see, and we go in with the extra time that we have and look at what we can for the instructor view as well. Essentially what we do and accessibility review we are looking for two things. We are checking for technical accessibility, so we're looking at how the Sakai code generates HTML and if that meeting, the best practices for accessibility relative to the accessibility goals as stated in the statement, which is the way 2.0. When looking for functional accessibility. You can code a site and make it meet the accessibility standards, but maybe it's still not completely usable. So one of the things we've created in (inaudible)  Luxor strips. At the Luxor strips are not completely specific on what to do, to basically detour to and talk about some of the concept that is they are and how to use it. But they are kind of agnostic to, they are not ready for specific adaptive technology for instance. That gives us the ability to use that in a broad sense for different users and Mary has done a lot of that texting so I won't let her talk about that.

Basically what happens is that walk-through script will tell you to login and go find this tool, for example, just as an example, one of the tools that can be evaluated on Sakai is the film's tool, so you might log on and see how many forms are, how many threads there are two each for them and if somebody reply to that and if that was easy to find. I come many people replied if that was easy to find and whether it was hard. And then you basically after you figure that out loud, then EU, we basically look for other things after we go through the walk-through script and check to see whether the site is marked up with good headings. Whether of the tables have table summaries if they are needed, and other things like that. So there are basically two steps that we perform when we check for accessibility.

One of the things that we've been really excited about this year, too is on the walk-through scripts now I Indiana University we've got a student that's using a Macintosh computer and says he's going to be doing some testing for us as well print a lot of the testing for Sakai is been pretty well limited to window life and jaws and a little bit of the DA as far as the screen (inaudible)  we also go through the walk-through scripts, testing the functional accessibility without using any adaptive technology at all, just to see if something is accessibility purely through the keyboard. For instance I will go through the walk-through script on the tool and click the mouse on the site and see if I can certainly use the keyboard and Internet Explorer as well as Firefox and try out some of the different browsers to see is a keyboard accessible. When we do the technical accessibility we have a testing protocol that is based off of using Firefox and a lot of the accessibility blogging so you can plug into it. When you go through those tools, they help you look at the website, maybe you don't have a screen reader for instance but a lot of those tools will aggregate content that you normally would have available to you as if you were a screen reader. For instance you can bring up a list of all the headings, bring up a list of all the links and it helps you look at whether the forms are controls for labels, whether the link tasks all make sense individually what would happen if you click on the link, are interlinked tasks that were the same (inaudible)  different functions. It gives us the ability to quickly look through the site and we can also go in and look at the code and make sure that how it is coded as appropriate. A lot of the things that we find when we do those testing are pretty simple. So maybe a form control like a text box in a form is not labeled, or a link is not specific to its functions. Maybe you have something that appears as a list, but actually they've used a series of BR tags and some graphics to make it look like a list. Maybe some controls are completely keyboard accessible or maybe even just that the instructions that they put on the page are ambiguous or (inaudible)  undecided users. A lot of those are pretty easy to fix and we can put in the bug report for that. Sometimes we can even submit our own taxed for the fix and get those reviewed and get the fixes made. One of the things that we wanted to go over are some of the features that are actually in Sakai are there to help make it more accessible. And one is the decided structure is marked up before heading for easy navigation. Some of these headings are hidden from the site user when they look at the site and they are there strictly for people who are using adaptive technology like a screen reader. If you remember those mini bars, one that goes across the top of the page that lists all the different worksites or classes that you have, there is a heading right above that explains what that is in the links for the websites are in a list and each of the links within the list is a link. And then the same thing as truth for the menu bar on the left that lists all the tools available to you. There is a heading right above that that announces what it is and there is a list of links. And that may exceed easy for someone to navigate the page by headings. They can just press H. or bring up the headings listed quickly view the structure of any page that they come to in Sakai. There's also access keys, shortcuts provided that give you direct access to the different sections of the page. So there's a shortcut key that takes you to the work site list, there's a shortcut key that takes you to the list of tools that there's a shortcut that takes you directly to the content on the page. Those are also links. So the screen reader for instance can bring up a list of links and depressed J., and then there are three links that say jump to content, jumped to work site list, jumped to tools list so you can quickly navigate around the page. Often times there is a table that served used for real data table, there's a table summaries Bush with a table has many columns that is somewhat complex the table summary will describe the layout of the table and what the different columns mean. We make a really big effort to make sure that all of the link texts are unique and meaningful within the Sakai so that if someone brings up just a list of links and is navigating the page that way each list or eat each link individually will tell you what its function is and what you can expect to happen when you activate it. Some of the challenges that occur when using Sakai for accessibility. The largest one is the WYSIWYG editor. And WYSIWYG stands for what you see is what you get and it's basically a JavaScript editor used in Sakai to provide rich text editing support. If someone wants to create content in Sakai and they want to have headings and maybe a tablet may be a list of things that they would use this editor and currently in Sakai we use a JavaScript editor called the SDK editor. It has many accessibility issues in it. The worst one is that it becomes a keyboard track. So if you are navigating to the page of the keyboard user and tapping along and you go into the editor you get stuck. If you pressed tab or shift tab chart to get out of the editor you are just basically doing what any normal afterward to which the tab, just inventing the tabs on the page or putting spaces in something. That makes it pretty inaccessible. Also the toolbar that it has that you would normally use to change the font size or select your using a paragraph or list or add in a table is inaccessible as well. For a while it used to work that you could type up a document in Microsoft Word and paste it in, but the SDK editor is old enough now that modern versions of Microsoft Word don't work without. So even going off to the side and typing or document type in word and just pasting it in no longer works. So the Sakai community is working on upgrading the vastly improved new version of that that is now called the SDK editor, for any of the music I to point X. releases and that's going to be a really great benefit for us and go along way to making Sakai more accessible. There are some workarounds for that now and one of the things is that especially as an instructor I said about the way a student can submit an assignment using Sakai and they would want maybe normally the student to actually type it into the SDK editor. They can include an option where the student can upload an attachment so that the student contacted document on their favorite word editor, Microsoft Word or OpenOffice Word or something like that. Save it and uploaded into the system. So that is a nice workaround that they have going on right now. Some of the other accessibility challenges that we have with Sakai. A lot of the code is written in various different versions of Java or Java scripting. And on the server side, so some of these older Java's page scripting technologies don't always generate code that is up to the accessibility standards. That's something we've been fighting a lot whether it is the tool that we do in accessibility evaluation of and we find out something, particularly is usually a form control that's not labeled appropriately and we go in and say hey, this thing should be labeled and they come back and say well without doing a lot of work, totally rewriting the tool we cannot help you because the technology that the tool is written in does not support that. So that's pretty frustrating. Another one is for the benefit and the pros and cons right list we have obvious developers across all these different universities, they don't always good things consistently. So not always not only are there different technologies out there that rendered the page differently, have a layout and menu, or how they layout controls on a form, the programmers themselves often do things differently, so maybe the search box is located in one place and one tools, located in a different part of the tool then the next one. So that can be frustrating to users, especially users of content with disabilities or screen reader users have developed certain navigation tricks that go into a new tool and have to reorient it themselves and try to understand why it's different in this tool than it is in the other (inaudible)  and other accessibility challenge that sometimes comes up in Sakai occurs specifically more common for instructors, maybe even teaching assistants who use Sakai. A lot of the tools have configuration stream so you can set up for instance, Mary was talking about the forms tool where you have all these different discussion forums where the instructor can set up a lot of different form what are the different forum topics are, they can create multiple forms and set up the rules for how students can interact and whether they can edit their own or delete their own postings for instance, for most tool configuration screens are technically accessible, but just really busy. So it's not easy for new users to figure out what's going on on the page and even some cases I have trouble with that and have to read the documentation. So I think that some accessibility challenge, just that some of the tools are somewhat complex. Usually not something that the student sees. So, what do we have coming for us in the future for Sakai? One as we already mentioned is the upgrade to the what you see is what you get editor. We're all pretty excited about that. The other one, they are is a new set of guidelines called the Web accessibility initiative's aria technologies come accessible Rich Internet applications. Those have some product promised to making the Internet Marxism will, but they are not very well supported at the moment across browsers have different stream readers. So we are pretty conscious about that but we are looking at adding goes into some places where they would be appropriate. A big one for us is the use of JavaScript technology where some routines can be called after the page is loaded and can use JavaScript to go and actually changed the way that page is loaded so there's other technologies that for instance might render a table with some form controls in a way that is not completely accessible, then we can use these JavaScript routines to actually go read out the pages in a way that is accessible. For instance putting labels on form controls or removing certain tables that are a separate page layout or whatnot. And another one we are starting to look at is the winter user interface consistency. Looking at tools and trying to figure out whether something should be changed in order to tools is laid out to make it more consistent, should the construction be worded the same way it is as a different tool, should the search box be located here versus here, trying to come up with some consistency for the tool as well. There's a new version of Sakai, kind of a next generation that is in development now. That would be Sakai three. That is pretty exciting change. It's going to be a much more modern looking system and we are going to be calling that an open academic environment. So Sakai likes to think of it not just as a learning management system, but as something more broad. And so they decided to call it an open academic environment. Essentially it's going to incorporate all the features and values that are within Sakai 2.0. But reimagined as something that supports all the functions of the academic life. Whether it be an instructor or a student. So what that really means is that they are trying to make it to where it is more social. So kind of going along the lines of where a lot of the web is going today. A lot of ability to network and connect with different students. And instructors. And also having a less rigid structure. A Sakai right now, pretty much all the content you put into it goes directly into the tools, so the tools of a certain format. You fill in forms, but the information herein the tool set in a fairly rigid structure. In the new version of Sakai UI people to create content in lots of different places, and on most anything, rate, review, even great. If a student puts a comment in the forum, thread, the instructor can actually create the student's comment and I would actually appear in the great book. Maybe Justin has to reply to so many different messages and somebody could actually go through and review of the messages and you get agreed on that. So, it is also the ability to create the process and not just the content whereas in Sakai to it's really rigid where the content goes, and in psychiatry we are actually going to create the flow of things and where you can put information and a lot of that's going to be a lot more flexible. So, essentially that all sounds pretty exciting, but what does that mean for accessibility? Well, the psychiatry interface is going to be significantly different and they are going to use that term a lot that we here in the language of widgets for the user interface there's going to be a consistent availability on the page strengthens the chat,, and (inaudible)  otherwise create content almost anywhere so that is going to require the understanding of navigating multiple contexts on a given page. You're going to have to know whether you are in a chat window or whether you are commenting on something or actually reading content for instance that was written by the instructor. So it's going to require some really strong organizational skills and consistency in Sakai as well as use of a lot of new technology is probably (inaudible)  to mark the different landmarks on the page for instance. So the ability as well then for the student to create content and method of creating content itself is accessible is going to be really important, more important than ever. So whether the WYSIWYG editor, or the what you see is what you get editor in Sakai now, we are going to have to make sure that is done really well and that is accessible and easy to use. Part of that comes from for the psychiatry accessibility statement we went in and added a new set of guidelines, under the option to accessibility guidelines of those guidelines look at what kind of features need to be in place so that someone can create content in Annex a simple manner in the web system. That is the end of the slides that we have prepared. I'd like to go ahead and open it up to see if there are any questions?

   Well, Brian and Mary, you did an excellent job and I hope some people have questions. You can either grab the mic to ask a question, or else you can put it into the text chat, go ahead.

   It looks like Holly has taken a question and I'm going to type, scroll back up to see that. The question, how do you reach users with disabilities to join your group and how much are they actively involved in finding accessibility solutions and suggestions? Well, essentially, that's a great question. We would love for people to join the accessibility working group. We posted a link to that group and the slides here.

   Honestly it's even easier to Google Sakai accessibility working group because it's pretty long but it is the first result that comes up. But if you did your screen reader, that's probably the best way. As far as users with disabilities, we do have a few in the working group. I'm actually one of them. There are two other people (inaudible)  on the IU campus who have disabilities. I have performed some Sakai testing or will be performing Sakai testing. There are a couple other people in our working group who also have disabilities. But, yeah, it would definitely be nice to find more people. Yes

  When you go to the accessibility page there's a link on how to get involved and they will talk about an e-mail list and essentially you could go to the webpage and join the e-mail list and jump right in and introduce yourself. There is also, there's also a series of conferences that we have, there's a schedule of those listed on the webpage and there's also a page on the wiki that lists some of the open meeting notes. Mary has been really nice and taken a lot of good notes from the past meetings, so you can go to and get a feel for what it is that we talk about and see if it's a place you would want to jump in. We welcome anybody to join the e-mail list and look around that even if you are not going to announce yourself and you just went to work on the list to see what's going on, that's fine. A lot of the people that we work with here at IU students that we've worked a lot with throughout the years, so we've asked them to help volunteer, some of them have expressed their own interest in wanting to do that we are going to go look and see what other questions we have (inaudible)  here is one from Lori. How do you find out whether Sakai is not accessible to the student, T. wait to hear from the student to say that he or she cannot access something through Sakai, or are you testing every instructor site? Also you talk about changing the code to make it more accessible. Who is responsible for this in your University and what is the process for making changes? There are two questions here, do you want to answer the first one, Mary?

Sometimes every once in a while we might find out something from a student I usually I've gotten a lot of the questions and (inaudible)  with Sakai, as far as the phone calls that I got for encore, and pretty much aware of the problems before a student will call, most of the time. Maybe 90% of the time. There have been a couple of times when I've been surprised but fortunately it hasn't been all that often. So I've been able to be there to give them answers or different workarounds. So as far as reporting the problem, Brian is now the lead for the Sakai accessibility working group and also Claudia Sherron, right? Yeah, so it's pretty easy to let them know about these problems. We have a system, Sakai has a system for reporting bugs and once that (inaudible)  you follow these tickets, and once the tickets get filled out and maybe Brian or you know, somebody will work on patches and they will get assigned to somebody and the person will be in charge of (inaudible)  the patches and we shall occur back and verify that the patches have been unlimited and the accessibility issue has been resolved.

   One thing we do two at Indiana University Paris apartment here on the Bloomington campus called disabled student services and any time a student gets into a class, they know that there's been a contact or adaptive technology Center here in for instance if an instructor posts information to Sakai PDF or Word document and its annex a symbol to them that we can work with the instructor to help make their content accessible and in some cases we actually modify and prepare an alternate version of the content ourselves and give it to the student. As far as who is responsible at the university for making changes, largely in all, the Sakai community at large is usually who we are working with, we are actually making some connections with the people who make our specific version of encore here at the Bloomington campus. They have their own (inaudible)  bug tracking system that will be working as part of the adventure of doing this kind of work is trying to figure out who is responsible for what tool you doing enough networking to know who is the main (inaudible)  and now who to talk to for this part of it. Let's see if we can come to another question. Our university is (inaudible)  suck Iowa should be suggested the faculty of implementors regarding accessibility? I guess the big thing we would look at there is just that the content gets plugged into Sakai. So, someone is posting a PDF, for instance there is a resource tool that a lot of instructors use that plugs course content to income and if they are posting a Word document or PDF, one of the first things that some of our student find challenging and finding the appropriate document making sure that the file name in the document is accessible and the filename itself is clear, so I documented this, that's really important. Sometimes instructors, PDF in the online academic databases and the name of that PDF is something like 6921J4621 and they have put that into the resource to ask `students to know what that is and that's the challenge.

The other thing is sometimes the sectors will use a (inaudible)  tool but they might decide to use some other tool to upload files and not necessarily tell the student, or they might not (inaudible)  remember. That's always been kind of an issue depending on the instructor as well. So that's not necessarily like the fault of any kind of web design or anything of Sakai is just one of dozens that happens.

A lot of the tools allow you to put attachments even a messenger sent an announcement, (inaudible)  but some summer house, the thing to do, to take him from that is just to provide some consistency and where you post information.

And I guess that's really important also that the editor that Sakai is currently using is not really all that accessible (inaudible)  attached a version of Sakai that they are using

Maureen asked a question, Lawrence asked a question he said what system does Sakai run on. Essentially most universities would be running Sakai on some kind of a UNIX box, whether that would be Red Hat Linux, or something of that nature. When I do development work on Sakai I can run it on my Macintosh computer, the (inaudible)  box on my desk, I've also used Windows to do that as well. It will run on the Microsoft operating system. It's basically running on Java technologies and there are different flavors of Java available for almost every operating system. So that is out there as well. Most of the code in the script and if you talk to the developers or read the instructions for installing it, they are all pretty well geared to UNIX-based systems. So if you have a Linux box, or an Apple Macintosh server or something like that it's going to be a lot easier to understand where that's coming from. But there are demo versions that you can use off of the website, either directly off of the Sakai project site itself, or you can download demo versions that can run on Windows or a UNIX box as well. Someone asked if we could provide contact information especially e-mail or phone number. I wrote that I had and give you an e-mail address for the adaptive technology Center. IUadapt@Indiana.edu.phone number is area code 812, 856-4112. And you can ask for Mary or Brian at that number. And they will connect you. I'm going to go ahead and type the phone number and onto the chat window. It looks like it interpreted my phone number as an emotion icon. There's a phone number without the parentheses. There is my e-mail address. I'm going to go ahead and release the microphone now and see if there are any other questions.

   Good, John B. for any other questions I want to make an official thank you AND AN OFFICIAL ENDING If people want to stay and talk, that's fine but we've learned a lot and Sakai sounds like a very exciting tool and worth learning about. Thank you Brian, thank you Mary.

   Thank you

   thanks