The Office of Housing Administration and the Residential Education Office are about to co-launch a website redesign process where they will be consolidating information from different servers and sites onto the Toolbox CMS. On the old site, they created a Java tool that has been helpful to prospective students in selecting residential learning communities.
http://starter.sdsu.edu/housing/find-your-hall.html
The tool is Java-based. Has anyone had success in including Java-based APIs in Toolbox? Assuming they can make the Java accessible, is it possible or not in the CMS? We are looking to provide any best practices and coaching available.
Toolbox Users Forum 
Sample of pulling your content in through an iframe…
This test is on a page under the Intercultural Relations header, but the principle would work for any free text area.
I only did this because I was the one who originally set up that “Find your hall” page, which I believe is relatively accessible. Maybe not *convenient*, but functional.
Ooops, it appears I left out the URL
http://newscenter.sdsu.edu/student_affairs/intercultural/test-page.aspx
Oh… one more thing…
“FAQ module”? What’s that??
Hi Keith – the ‘FAQ’ module is supported in the non-spaces/2012 template within the CMS. Think of it as built to present frequently asked questions in a list on a page with each question linked down the page to an anchor for each answer. When the Spaces/2012 template was built that module wasn’t included in those that received the Spaces/2012 treatment but is there for the older layouts (as are other modules). Please let me know if you’d like more detail!
Dan,
I can understand the concern with people adding code into the CSM that would result in non-508-compliant pages. Since you were tasked with delivering a compliant system, you’d want to make it as nonbreakable as possible.
But the fact that users can add their own CSS already makes it breakable to a degree. Someone could easily customize the text and background colors such that the content would not pass a color contrast test. Let alone having the content within the free text areas properly marked up to make it more assistive-tech friendly. So there is already a degree of self inspection and self policing necessary beyond the pages achieving a passing grade from our Compliance Sheriff scanning tool.
As for adding additional javascript into the mix, I know that with jQuery, for instance, there are many plug in scripts for a variety of tasks that call themselves “accessible”. Whether they actually meet the CSU 508 guidelines that we’re supposed to uphold might be another thing that the individual site creator would have to confirm, beyond the page passing the automated scan. (That’s what I personally think we should do.)
BUT, from the larger perspective, it may be a can of worms that we should just leave closed. If people need scripted functionality on a page, just host that page outside of the CSM. Either link out to them, or pull the content into the CMS-based page via an iFrame.
Of course, having noncompliant pages outside of the CSM is *still* a problem, but at least it leaves the CSM less breakable.
Thanks Keith for the explanation – that’s all terrific. One of our hesitations with loading external .js files is the potential for cross site scripting vulnerabilities being exposed. That being said…my biggest concern with any of these manual javascript options is accessibility/Section 508 related. Just adding the accordion functionality or what housing has on their web site without adding the similar equivalent for non-clicked/sighted users will be a Section 508 violation as I interpret it. The sort of functionality in both the accordion and what housing has to some extent is available in the FAQ module but I certainly understand that it isn’t as interactive as something javascript-based. What I’d like to do is get this on the wishlist to both address accessibility and functionality concerns simultaneously.
First off, it is “javascript”, not “java”. (If we’re going to have a technical discussion, we probably ought to be precise.)
Second, the accordion code from the earlier post *is* javascript, so someone already has been successful with it.
And since the CMS already by default loads the jQuery minimum scripts, it would seem like you could do a lot with some additional inline scripting that tapped into that existing (potential) functionality. But I think for that you need someone who actually *knows* javascript, who can write and debug the stuff.
Alternatively (and I guess this should go on the Wish List) let people link to external JS files, just as they now can link to external CSS files. That would open up a huge range of possibilities (since jQuery is so user-friendly), and I think is generally the more efficient way to go compared to inline scripting (like the accordion script).