[cle-release-team] [WG: Accessibility] SAM-1692

Mon Nov 19 13:12:54 PST 2012

First thing: We should set the Content-Language header rather than using a meta http-equiv: http://www.w3.org/International/questions/qa-http-and-lang

This is almost certainly not enough, but it might help.

At the very least, we should also emit the right lang attribute on the html tag in the main portal frame. Given that the lang attribute is element-scoped, i don't think this would cascade to tool frames, but it will help. It may even take over if the frame has no lang specified (kind of doubtful on this, though). But if the header goes out by way of the ToolPortal and there is nothing in the document, we should catch more than nothing.

As Steve says, the larger issue depends on the UI toolkit used (to pick up the change corresponding to what would happen in the portal above). Having been concerned with "everything" by way of the CKEditor work, I ran into some of this (where we chose to do the editor logic at the edge rather than centrally). It's really not that bad to get central info down to a UI toolkit. If we picked up velocity, JSF, and OSP (as a bit of one-off in its XSLT views), we'd hit a very significant portion.

Granted, this would require a recompile of all of the tools, but the change may not that invasive. Also granted, the plain text issue (RSF/Wicket/others where the tool pages own their whole tool frame) may require changes-per-tool if there isn't some rendering override available on a large scale (though RSF does some of this with, e.g., stylesheets, so those tools may be pretty cheap to fix).

It would require some testing, but it may also be possible to use some before-onload (a la jQuery .ready()) script that tries to update the documentElement. This may not take effect, depending on when the readers engage -- at DOM completion or body onload.

In all, I'd agree on not targeting 2.9.1 yet, but suggest getting on it in trunk/2.10 to see what the hit rate and effort look like. If it's easy and tests out well, we might as well target 2.9 ASAP.

Thanks,
-Noah

On Nov 19, 2012, at 3:20 PM, Neal Caidin wrote:

> cc'ing the International group as an FYI.
> 
> Sounding more and more to me like we should not target 2.9.1 for this issue.
> 
> -- Neal
> 
> On Nov 19, 2012, at 3:13 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
> 
>> The fix required is no longer a samigo issue. 
>> 
>> It will touch every page of every tool, since it goes into the HTML attribute for the page. And the fix may be very difficult for tools that use plain HTML templates like RSF, Wicket, and possibly Trimpath. 
>> 
>> This has obviously been 'broken' for a very long time, probably since the beginning of Sakai, so I am skeptical that it has only just become an issue for screen reading software. 
>> 
>> There is a lot of work in resolving this. Are we 200% sure that the fix suggested is the correct one? What if there is no default language declared in the HTML tag? What happens to the screen reader? That would be easier than trying to make every page dynamic, if it worked.
>> 
>> Cheers
>> Steve
>> 
>> Sent from my iPhone
>> 
>> On 20/11/2012, at 6:50, "Humbert, Joseph A" <johumber at iupui.edu> wrote:
>> 
>>> If the change sets the primary language attribute to the user specified language,  it should fix the problem according to the comments.  I'm not exactly which tools are effected by this.  Anyone could test this I would assume by changing the language in the user settings and checking the primary language attribute of the HTML element to make sure it matches.  Our student tester, who tested this before, is out of the country currently.
>>> 
>>> According to the comment it looks like at overarching ticket is needs and sub-tasks for each instance.  I'm not sure how much work this would take, but I can devote time to testing today, tomorrow and next week.
>>> 
>>> 
>>> Joe Humbert, Adaptive Technology and Accessibility Specialist
>>> UITS Adaptive Technology and Accessibility Centers
>>> Indiana University, Indianapolis and Bloomington
>>> 535 W Michigan St. IT214 E
>>> Indianapolis, IN 46202
>>> Office Phone: (317) 274-4378
>>> Cell Phone: (317) 644-6824
>>> johumber at iupui.edu
>>> http://iuadapts.Indiana.edu/
>>> ________________________________________
>>> From: Neal Caidin [nealcaidin at sakaifoundation.org]
>>> Sent: Monday, November 19, 2012 2:39 PM
>>> To: Humbert, Joseph A
>>> Cc: cle-release-team at collab.sakaiproject.org; accessibility at collab.sakaiproject.org
>>> Subject: Re: [WG: Accessibility] SAM-1692
>>> 
>>> Hi Joe,
>>> 
>>> Do you think we will get this tested in time for 2.9.1 ? Who would be in a good position to test this change?
>>> 
>>> It wasn't clear to me if the changes actually fixed the problem or if this is an interim workaround? (maybe needs a new ticket for a more comprehensive fix?)
>>> 
>>> Thanks,
>>> Neal
>>> 
>>> On Nov 19, 2012, at 2:31 PM, "Humbert, Joseph A" <johumber at iupui.edu> wrote:
>>> 
>>>> It can cause significant issues for international users of adaptive technology.
>>>> 
>>>> Joe Humbert, Adaptive Technology and Accessibility Specialist
>>>> UITS Adaptive Technology and Accessibility Centers
>>>> Indiana University, Indianapolis and Bloomington
>>>> 535 W Michigan St. IT214 E
>>>> Indianapolis, IN 46202
>>>> Office Phone: (317) 274-4378
>>>> Cell Phone: (317) 644-6824
>>>> johumber at iupui.edu
>>>> http://iuadapts.Indiana.edu/
>>>> ________________________________________
>>>> From: accessibility-bounces at collab.sakaiproject.org [accessibility-bounces at collab.sakaiproject.org] on behalf of Neal Caidin [nealcaidin at sakaifoundation.org]
>>>> Sent: Monday, November 19, 2012 1:15 PM
>>>> To: cle-release-team at collab.sakaiproject.org; accessibility at collab.sakaiproject.org
>>>> Subject: [WG: Accessibility] SAM-1692
>>>> 
>>>> Hi all,
>>>> 
>>>> A couple of questions about SAM-1692.
>>>> 
>>>> https://jira.sakaiproject.org/browse/SAM-1692
>>>> 
>>>> 
>>>> It looks like it touches a lot of tools. If we include this in 2.9.1 will this require a lot of regression testing? The change does look almost trivial though. Just wondering if this merge should be targeted for 2.9.1 or not? Still requires validation testing.
>>>> 
>>>> Thanks,
>>>> 
>>>> Neal Caidin
>>>> 
>>>> Sakai CLE Community Coordinator
>>>> nealcaidin at sakaifoundation.org
>>>> Skype: nealkdin
>>>> AIM: ncaidin at aol.com
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> accessibility mailing list
>>>> accessibility at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>>>> 
>>>> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>> 
>>> _______________________________________________
>>> accessibility mailing list
>>> accessibility at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>>> 
>>> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20121119/1288dcf2/attachment-0006.html 