Discussion about accessibility in the 2.0 release. See the "General" page for background information about Sakai accessibility.
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
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.
I have added a draft timeline for evaluation and revision of 2.0 tools to be 508 compliant by Fall 2005. See attachment above.
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.
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?
Note that a list of accessibility elements used in the tools refactoring is contained in the above file:
Note that I have posted to this site a draft schedule for 2.0 accessibility review and revision:
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.)?
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.
This is different from the WCAG1 where you had to provide an alternate for all these other technologies.
There's been significant support for the "baseline" concept and it appears the WCAG2 will include it however it's not 100% certain.
On Monday, October 10, 2005, at 08:01 PM, Allison Bloodworth wrote:
I was reading through the Accessibility statement and was wondering about this part:
In Client-side Scripting Techniques for WCAG 2.0 (http://www.w3.org/TR/2004/WD-WCAG20-SCRIPT-TECHS-20041119/) 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."
Which of the following are required under Section 508?
The Web page must function when scripting is disabled?
Thanks very much,
Principal Administrative Analyst
e-Berkeley Program Office
Universityof California, Berkeley
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:
Best regards and thanks,
On Oct 11, 2005, at 12:48 PM, Allison Bloodworth wrote:
AB: Chris' comment I was referring to was:
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."
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.
I think Mike has answered your questions but I'll add a few comments too.
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.
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.
Thanks much for the additional information. I just a few questions:
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?
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?
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.
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.
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.
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?
"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)
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.
Web Accessibility Instructor
High Tech Center Training Unit for the
California Community Colleges
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?
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.
>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 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.)
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.
Information about what IBM has done to make their millions of pages accessible:
The article is also provided as an attachment
Note that the url for this article has been changed:
Powered by a free Atlassian Confluence Open Source Project License granted to Apereo Foundation. Evaluate Confluence today.