Skip to end of metadata
Go to start of metadata

Discussion about accessibility in the 2.0 release. See the "General" page for background information about Sakai accessibility.

  • No labels


  1. Accessibility (even beyond Section 508's requirements) is certainly
    something that Sakai is committed to. To that end, accessibility
    standards were adopted early on that exceeded 508, and met WCAG 1.0
    priority one, two, and, in some cases, three guidelines. The current
    style guide was developed based on those standards, and wireframes in the style guide contain accessibility tags and elements. That said,
    accessibility has been playing catch-up to Sakai's overall development.
    The overall priority has been to make Sakai work, rather than make it

    In general, I don't think we are that far away from being compliant.
    The refactored tools were based on the style guide and, though not
    perfect, work pretty well with JAWS. The big challenge will be to make
    changes to the wrapper and the way it interacts with the tools so that
    the whole experience becomes seamless and navigable with a screen
    reader. From a practical standpoint, it really doesn't matter if the
    tools are compliant, if the path there isn't.

    I will be meeting early this week with team members to talk about
    the technical issues we face in making the outside of Sakai compliant
    and supportive of the inner tool experience. We've also discussed
    accessibility this last week during the tools team meeting and I will
    be putting together a plan for testing the refactored tools, while we
    address the wrapper issues.

    So, I guess in summation, I would say we're not there yet, but we're on
    the case.

  2. Recent (May 17) email about the Indiana AT testing on March 7, 2004...

    Their usability test is interesting since it provides the perspective of a screen reader user. it points out that the need to make some additions to the style guide and changes to the application. For example, although the icons (with alt tags) can be helpful in the schedule, the legend itself is probably unnecessary and confusing for a screen reader user (doh). There also needs to be feedback to the user that input has been received and accepted (in the style guide...not sure).

    Other things we've discussed are worth repeating: Labels need to be better differentiated (probably through titles) and more consistent. Frames should have meaningful titles. Forms and tables should be properly tagged. Popups should be avoided. Accessibility information from a screen reader's perspective needs to be included, including suggestions for AT settings. Refresh and turning off refresh is a problem. Input buttons (like checkboxes) shouldn't be in tables. Subcategories can be confusing (like in Help) due to a lack of heading and subheading tags.

    I think we've covered everything in the last paragraph in the style guide, but I'll look it over to be sure. I know you and the tools team have been trying to get as much accessibility as possible in reach release, but I'm not sure what's gotten in, so let's get together when you have a minute so I can know for sure what we've been able to include in 1.5.1 and 2.x. That way I can put together some documentation on accessibility for 1.5.1 and 2.0, and we can start plotting how to get the rest in 3.x.

  3. I have added a draft timeline for evaluation and revision of 2.0 tools to be 508 compliant by Fall 2005. See attachment above.

  4. On May 21, 2005, at 2:40 PM, Michael Elledge wrote:

    Unfortunately, the portlet is at once the most important and problematic accessibility issue we face. One of the problems is that there isn't seamless navigation from the wrapper to the iframe content. In other words, screen reader users should be able to surf through the site in a hierarchical way using headings, links or frames. Right now the content provides that "look", but the external stuff doesn't.

    Any thoughts?


    On Saturday, May 21, 2005, at 09:09 AM, Gonzalo Silverio wrote:

    The portal was not touched in this regard. As you know it is no longer a template, but a Java servlet. This makes things a bit more difficult for someone like me to work on.


    On Friday, May 20, 2005, at 12:20 PM, Gonzalo Silverio wrote:

    All the legacy tools conform to the SG.


    On May 20, 2005, at 12:19 PM, Michael Elledge wrote:

    Hi Gonzalo (and Daphne)--
    Can you put together a list of the accessibility tags (etc.) we've been able to include in the 2.0 tool refactoring?

    Also, Daphne, what do you think is possible for the 2.1 release? Can we refactor the remaining tools? Anything else accessibility-wise beyond that?


  5. Note that a list of accessibility elements used in the tools refactoring is contained in the above file:


  6. Note that I have posted to this site a draft schedule for 2.0 accessibility review and revision:


  7. Mike Elledge discussion with Chris Ridlap of the ATRC about WCAG 2.0 Requirements wrt to Baselines.

    CR: There's text in the current WCAG2 draft that tries to explain what the baseline idea is all about:

    ME: I'm still a bit confused about the "baseline" idea, though. Is it something that we, as providers of technology, determine?

    CR: Yes, the technology providers determine the baseline. You can say that for your baseline all users have access to certain user agents and certain assistive technology. You are then responsible for creating content that is accessible to just them.

    I believe that the Sakai baseline should be quite broad. You should assume that Sakai will work with most modern browsers and most assistive technology. It would be wrong to target only one version of a certain browser and only one assistive technology.

    ME: Or is there going to be a W3C standard for adaptive technologies that we have to support at a minimum (JAWS 5.5, HPR 3.04, etc.)?

    CR: I don't think there's been talk of a minimum standard. The Sakai baseline should be any browser that supports Javascript and CSS which is not asking too much of the users.

  8. Mike Elledge conversation with Chris Ridlap of ATRC about WCAG 2.0 Requirements and Javascript alternatives.

    ME: I was trying to figure out whether the 2.0 guidelines will require applications to work with javascript turned off, and it seemed like it would depend on the WCAG benchmark applications (which I couldn't find).

    Is this your understanding as well?

    This is important since Sakai relies on JS for some of its operations and it may be difficult to duplicate some functionality.

    CR: It's looking like the WCAG2 will allow you to comply even if your application requires JavaScript. If your application does not function with JavaScript turned off then you can still comply.

    This is part of the "baseline" technology assumptions that are part of your compliance statement. For Sakai we would say that it complies with WCAG2 and we have a baseline assumption that JavaScript is provided.

    This is different from the WCAG1 where you had to provide an alternate for all these other technologies.

    Of course, our JavaScript would have to be accessible (all functions are keyboard accessible etc.).

    There's been significant support for the "baseline" concept and it appears the WCAG2 will include it however it's not 100% certain.

    1. On Monday, October 10, 2005, at 08:01 PM, Allison Bloodworth wrote:

      Hi Mike,

      I was reading through the Accessibility statement and was wondering about this part:

      "Sakai relies on JavaScript for some basic top of page operations, including setting permissions and options. It is our understanding that javascript will be permitted under the upcoming WCAG 2.0 guidelines, so at this point we have chosen not to provide alternative, non-script functionality. Instead we will note within the Accessibility page in help that JavaScript needs to be enabled (per WCAG 2.0 benchmarking) for Sakai to work."

      Can you tell me what the source of this information was? When you say that Sakai "Sakai relies on JavaScript for some basic top of page operations, including setting permissions and options," I may be wrong, but that sounds like things that could cause serious problems for users with Javascript turned off. In our application development process we only use Javascript in ways that will still allow users with Javascript turn off to use the application without losing any major functionality.

      In Client-side Scripting Techniques for WCAG 2.0 ( it says:

      In addition, authors should consider whether they genuinely need to use script in certain situations, or whether they can augment an HTML-based solution with script so that users with script turned off may still use the document. It is always important to adopt the least-restrictive set of technologies possible when authoring Web content. Or, as Postel's Law suggests: "Be liberal in what you accept, and conservative in what you send."

      And the Web Accessibility in Mind website

      Which of the following are required under Section 508?

      The Web page must function when scripting is disabled?

      * Section 508 requires that the content and functionality introduced by scripting be made accessible. The Web Content Accessibility Guidelines require that Web pages function when scripting is disabled. To achieve higher levels of accessibility, your Web pages should function with JavaScript disabled.

      • The Web page must be navigable using the keyboard
      • JavaScript must not interfere with keyboard navigation. It must not require the use of a mouse.
      • Content or functionality introduced by scripting must be make accessible to assistive technologies.
      • Screen readers and other assistive devices must be able to access all content and functionality introduced by scripting.
      • The user shall be given control over time sensitive content changes
      • Users must be alerted of content changes and given sufficient time to indicate more time is required

      The WCAG 2.0 Scripting Techniques Contributions site ( gives examples of several different ways that Javascript might be used and still remain "compatible with the goals of Web accessibility." These include things like forms validation, rollover images, pop-ups, menu systems, etc.

      If additional uses of Javascript will eventually be endorsed by WCAG, that would certainly be helpful to me in relation to a variety of development projects, so any information you can give me would be appreciated.

      Thanks very much,

      Allison Bloodworth

      Principal Administrative Analyst

      e-Berkeley Program Office

      Universityof California, Berkeley

      (415) 377-8243

      1. Hi Allison--

        Thanks for your comments and question. The source of my information is Chris Ridpath of the ATRC at the University of Toronto. It is my understanding that he has been working with the W3C as they develop the 2.0 guidelines. You can find our conversation on Confluence:

        At this point we are concentrating on improving other aspects of accessibility. With the requirement somewhat up in the air, I decided to deploy our resources where the needs are more immediate, but that doesn't mean that we won't address the javascript issue. It is, unfortunately, more difficult to create an alternative when paths are generated dynamically, and do not have static addresses. Our javascript also governs basic functionality, rather than drop down menus or forms for which there are easier solutions. Fortunately, the javascript in Sakai is compatible with JAWS.

        As you point out, though, Section 508 is more problematic. Hopefully it will evolve as WCAG 2.0 is introduced. Let me know, though, if you have found instances where javascript has caused a problem for users so we can be sure to address their needs. And if there's a ready non-javascript alternative to how we're using it please let me know--that would be the best solution of all!

        Best regards and thanks,


        1. On Oct 11, 2005, at 12:48 PM, Allison Bloodworth wrote:

          AB: Chris' comment I was referring to was:

          CR: It's looking like the WCAG2 will allow you to comply even if your application requires JavaScript. If your application does not function with JavaScript turned off then you can still comply.

          This is part of the "baseline" technology assumptions that are part of your compliance statement. For Sakai we would say that it complies with WCAG2 and we have a baseline assumption that JavaScript is provided.

          This is different from the WCAG1 where you had to provide an alternate for all these other technologies.

          Of course, our JavaScript would have to be accessible (all functions are keyboard accessible etc.).

          AB: It seems that he is saying that an application could use JavaScript, but the functions provided by the JavaScript would have to be keyboard accessible. Is that an incorrect interpretation? If so, it sounds like Sakai wouldn't pass that test.

          ME: Although it's not yet to where we want it to be, Sakai is definitely keyboard accessible, with javascript functionality amended with "onkeypress" tags, and substantial use of accesskeys, skip links, titling and headings. Forms and tables also follow WCAG recommendations. But we aren't perfect, so please let me know where you've found problems so we can get them into the Jira queue.

          AB: In re: to the baselines, it sounds like baselines should be set only if they are supported by accessible user agents:

          "WCAG 2.0 therefore does not require or prohibit the use of any specific technology. It is possible to conform to WCAG 2.0 using both W3C and non-W3C technologies, as long as they are supported by accessible user agents."

          "In choosing technologies to rely upon, developers need to know what technologies they can assume are supported by, and active in, accessible user agents. A set of such technologies is called a baseline."

          AB: I also did some Googling around trying to find information on how well screen readers support Javascript. It seems that it is still unclear, and that javascript may sometimes may work properly in a screen reader and sometimes it may not:,

          AB: Wouldn't it then be too early to say that Javascript is truly supported by accessible user agents, like screen readers?

          ME: I have found that Sakai works pretty well with JAWS, although, again, there is room for improvement. We have two testers who are screen reader users and we've put the issues they've found into the queue. I typically use version 4.2, which is several versions behind the JAWS 7.0, the most current iteration, so we're not relying on state of the art software, although I am sighted so my perspective is going to be different. We have done limited testing with Window-Eyes, although I suspect if it works with JAWS it will work with W-E. Again, if you've found some particular problems, please let me know.

          AB: Thanks again for your help with this issue,

          ME: No problem at all. I want you to keep raising issues and asking questions. We need your (and the larger community's) participation.

          1. Hi Allison,

            I think Mike has answered your questions but I'll add a few comments too.

            Regarding the use of the Javascript:

            If the Javascript is purely decorative then you don't need an alternative. An example of purely decorative Javascript is when it is used to create links that change color when you mouse over them. Screen reader users do not need this information and it may actually be a hinderance if you informed them each time the link changed color.

            If the script is not purely decorative then the script must be accessible. This means there should be things like 'onkeydown' attributes for all the 'onmousedown' attributes so the script is keyboard accessible. It seems that Sakai is doing most of these things.

            Allison asked "Wouldn't it then be too early to say that Javascript is truly supported by "accessible user agents" (screen readers)?"

            This has been a difficult question to answer which is why the whole baseline part of the WCAG2 was created. At what point is it OK to use Javascript without an alternative? The same question also goes for PDF and other non W3C technologies. The answer is that you can use these technologies now as long as they are accessible. Unfortunately there will always be a percentage of users that can not access your content.

            This issue is similar to the minimum angle used for wheelchair ramps. To be accessible, buildings must have ramps of a certain angle. But even that minimum angle may be too difficult for some users.

            I hope this helps.



            1. Hi Chris,

              Thanks much for the additional information. I just a few questions:

              1) Mike said Sakai was using javascript to "do top of the page operations", so these are all things users can access via keyboard shortcuts? When I initially read this I thought he meant something happening behind the scenes, like in uPortal where the page URLs are re-written, that the user would never be able to access and thus would render the page inaccessible if javascript wasn't enabled. I assume that is not the case and he just means that after the user presses a button to set a preference, javascript is used to do it and the user can access that same button through a keyboard shortcut? I looked at the javascript file in the UCB implementation of Sakai 2.0, bSpace, and wasn't able to find any of the javascript functions listed except "openWindow" in an actual page, so I wasn't able to tell whether they all had keyboard shortcuts.

              2) You say below that "there will always be a percentage of users that can not access your content" with the concept of baseline means that you assert that there are enough accessible user agents supporting javascript in a predictable and/or uniform way (or at least do it properly for the javascript functionality on your site) that you are requiring that your users access your page with one of those user agents. If they choose not to use one of these user agents, the page won't be accessible but that is OK.

              3) Are the 2.0 Guidelines what "should be followed" right now even though they are a Working Draft? Or do we follow 1.0 until they become a Recommendation?

              Thanks again!

              1. Allison,

                I'll try to answer your questions:

                1) I'm not sure exactly what the "top of the page operations" are. Perhaps Mike could explain?

                2) For Sakai, the baseline assumption is that most users have Javascript enabled user agents. At this point, 2005, I think that's a good assumption. I haven't checked over all the Javascript but generally it seems to be OK. If a user chooses a browser that doesn't have Javascript then it's possible they may miss out on some things. It appears that even with no Javascript, everything should be accessible in Sakai (did you spot something that wasn't?).

                3) There are several problems with the WCAG1.0 that will be fixed in WCAG2.0 so I think it's better to shoot for the 2.0 guidelines. They are getting closer to recommendation and should reach that in 2006. I think we can still get almost 100% WCAG 1.0 conformance with what we've got now.



                1. Hi Everyone--

                  What I mean by top of page operations are the functions typically found at the top of the content page. For example, typical items would be options (how a page would appear), add category or expand all (for discussions). They most often appear in the Administrator view, but control functionality (such as save, cancel, etc.) for Students, too.

                  Javascript enables these functions to work. So, for example, with js off, you can navigate to the Add Category button, but it won't work.

                  The issue of whether Sakai is able to require js is critical to its ability to work. The difficulty is that there appears to be no easy non-js fix, since content is generated on the fly, and addresses are not static. So the html based <no script> static alternatives, with which I am most familiar, don't provide a solution. Perhaps there is another approach that I don't know about (if there is, please tell us!).

                  Hope this helps.

                  1. Anonymous

                    Hi Mike,

                    I'm don't know of any non-javascript fix for this either. It's pretty clear that someone without javascipt would be missing some integral functionality in some places. Another place I can think of (which I can't find an implementation of in UCB's instance of Sakai, bSpace) is the "Side-by-Side" Lists UI Component in the Style Guide. Without javascript, the page would have to be refreshed each time an item is moved from one side of the page to the other. So unless it is implemented in this fashion (which would be slow), it would be completely inaccessible to non-javascript users.

                    I guess based on the information we've gotten from Chris, the answer is to test that all javascript functionality works properly in the leading screen reader software (e.g. JAWS, Window-Eyes...potentially testing on multiple versions) and then specify that users must have one of these. Does that sound right?


                    1. Hi Allison--

                      That sounds right. Just as Sakai recommends certain browsers, we should identify which versions of AT software are recommended and/or required. It would make sense to include this in the Sakai accessibility section, which already recommends certain screen reader settings and navigation techniques.

                      In addition, we should provide links for downloading screen reader, etc. updates for AT users, so they can upgrade their software as necessary.

                      This would be a good time to start collecting a list of AT software and devices used by persons with disabilities, so we can take a comprehensive approach. JAWS and Window-Eyes are obvious. How about Zoomify and Kurzweil? Are there others out there we should test?


                      1. The following is from an email exchange about Sakai's JavaScript I had with Sean Keegan, Web Accessibility Instructor at the High Tech Center Training Unit for the California Community Colleges. The HTCTU provides software evaluation and support to community colleges in California as they comply with California's accessibility requirements.

                        Hi Mike,

                        "Although it appears this will not be a problem under WCAG 2.0 recommendations, it is a problem under the current 1.0 recommendations and Section 508. Any thoughts about how concerned we should be about the discrepancy?" (Mike Elledge question to Sean)

                        I think it is more of a problem under the W3C WCAG 1.0 guidelines than 508. From the discussion list, it appears that j/s (javascript) is being using to write information to the screen as well as control page permissions - correct?

                        Section 508 1194.22 (L) allows the use of j/s so long as the content displayed to the screen is available as functional text (e.g., if using the document.write function, etc.). If it is text, then it can usually be accessed (in some manner) by assistive technology - the only sure way of determining is to try it out with a screen-reader. The 508 standard is not so much concerned about functionality with j/s disabled as it is about ensuring functionality for assistive technologies with j/s enabled. Based on the comments that I have seen on the list regarding how j/s is used in Sakai, as it would not appear that the 508 standard is restricting its use.

                        I think the real difficulty is conforming to the WCAG 1.0 guidelines with respect to j/s (in particular checkpoint 6.3). If the information is important and j/s is disabled, then to conform with checkpoint 6.3 the information would have to be made available. If it is not possible to use ensure the page is usable with the script disabled, then checkpoint 6.3 allows you to post the content on an alternative text page (but this may not be feasible in the workflow/design of Sakai).

                        Where do I stand?

                        With respect to following W3C guidelines, I would suggest focusing on the W3C WCAG 2.0 guidelines (IMO, these guidelines are more suited to current Web technologies) as well as the 508 standards. True, the WCAG 2.0 is in draft format, but I think it provides the most flexible option to balance current Web technologies as well as accessibility.

                        However, even by following the standards and guidelines, it is necessary to run tests with assistive technology (as well as keyboard) to ensure that accessibility of the content is available to user agents and does not disrupt assistive technology on the page. My concern is not so much on whether the platform functions with j/s disabled (as most Web users have no idea how to even disable j/s), but rather does the implementation of j/s in Sakai provide for keyboard and assistive technology access.

                        Not sure if I answered your question, but I would not consider the current discrepancy to be that major right now.

                        Take care,

                        Sean Keegan
                        Web Accessibility Instructor
                        High Tech Center Training Unit for the
                        California Community Colleges
                        Cupertino, CA

  9. The problem of multiple iFrames and redundant titles
    We currently have two iFrames for each tool content area, one for the title of the tool and another for the tool's content. This is the legacy of a decision made long ago that probably is no longer relevant to Sakai functionality. It is a problem for accessibility, since it results in multiple mentions of the same information (example: "Begin message of the day title frame...Message of the day title frame...end message of the day title frame...Begin message of the day content frame...message of the day content frame...Message of the Day...end message of the day content frame..." Even with the setting as "do not announce frame beginning and end" there is too much redundancy. I had hoped that placing "" as the title of an iframe would result in JAWS skipping over the tag, as it does with <alt> tags. Alas, it defaults to the iFrame name, which is even worse ("Titlexgatewayx110").

    The only solution I can see is combining the two iFrames, which will require a fair amount of recoding and revision (such as changing content heading tags). This is, by the way, already in Jira as an issue to be resolved for 2.1. Can anyone suggest some other simple, short-term fix in the meantime?

  10. Since the State of California has requirements for courseware accessibility, I asked Sean Keegan at the HTCTU (The High Tech Center Training Unit of the California Community Colleges) to describe the process they use for evaluation. Originally, I thought we might use their protocol, but Sean was tied up on several projects and only recently got back to me. However, I still think that their approach is instructive, especially since it looks for the same issues as we do.

    I've asked a follow-up question about our use of Javascript and pending changes to the WCAG 1.0 recommendations, and whether he feels that we will run afoul of the state's requirements in the interim if we don't have js alternatives. I will post his replay as soon as he gets back to me.

    >Would it be possible for you to share your evaluation protocol with us?

    The evaluation protocol I use depends on what we/I am being asked to investigate. Officially, we do not evaluate any technologies. However, I do respond to questions from the field (Ca Community Colleges) regarding questions as to a) how, or b) if, a piece of assistive technology works with a specific Web technology.

    Internally, I use the Section 1194.22 from Section 508 (technical standards for the Web) to complete a "first-run" assessing if the appropriate code has been included for various tags. I use several different evaluation tools in this process to see if I get different results (lately this has included AccVerify/AccRepair, A-Prompt, and LIFT).

    I follow this by running the content in question through a Transcoder; basically this removes images (and replaces the images with alt-text), style sheets, layout tables, and javascript. This is a "second-run" to evaluate some usability concerns, such as logical reading order, if semantic markup was used (or used properly), if data formatted with data tables contains the correct code (properly coded data tables retain the "table" look), if there is a problem with javascript disabled. I also review the page title, and link titles where appropriate.

    (I am not a big fan of transcoders being used as a Web accessibility solution, but if you know what to look for they can be a very helpful Q/A tool.)

    Lastly, I run a few pieces of assistive tech. on the page, focusing on the following areas: javascript issues (can the content be activated/used with the assistive tech.), use of multimedia (captions included, how is the multimedia presented to the user), form functionality with assistive tech., and the functionality of non-HTML/XHTML technologies (PDFs, PPT, Flash, etc.).

    While I start with the 508 technical standards, I also include testing in the usability arena. I think the 508 standards are a good place to start, but (IMO) it is also important to evaluate whether or not the individual can actually make use of the information on the page/site.

    I hope this answers your question. I do not know if you are looking for additional evaluators/testers for the system, but I can be available if necessary.

  11. Here's a link to what appears to be an excellent article (quite technical) on making javascript accessible from the CSUN conference:

  12. Information about what IBM has done to make their millions of pages accessible:

    The article is also provided as an attachment