[WG: Accessibility] [Management] Fwd: Sakai 3 Capabilities and Accessibility

Richwine, Brian L brichwin at indiana.edu
Wed Nov 11 21:04:49 PST 2009 

RE: the CK v. Tiny debate:
Yes, CK's use of the arrow keys for navigation between controls in the toolbar is closer to the convention used by many DHTML and Web 2.0 widgets and users are probably beginning to grow accustom to that. It is disappointing that (at least in the demos we tried) they both required the use of a special access key to get in and out of their toolbars. I wonder what the proper use of ARIA landmarks would be in this case - would use of landmarks for navigation be restricted for between "widgets" on a given page, or could landmarks be set so the user could move into the toolbar and edit window?

I noticed on TinyMCE's website that they switched to using real drop-downs in the toolbar on their "accessible" demo example (example 17), so it seems that there might be various installation/configuration options that affect the implementations accessibility.

The big advantage Mary found in the TinyMCE editor, is that JAWS didn't seem to get out of sync with content in the document. With the CKEditor, Mary found that after accessing the toolbar or any function that brought up an editor's dialog, then JAWS either thought that all the content disappeared or got otherwise out-of-sync. Mary had to keep toggling the JAWS virtual cursor off and then back on to get JAWS sync'd back up again. This procedure is actually outlined in the CKEditor's documentation. At first it caused a good bit of confusion of course, but even after learning about the need to toggle the virtual cursor on and off, it was still rather annoying. Besides being annoying, it might cause the user to make errors in editing.

Both TinyMCE and CKEditor have icons on their toolbars that look like help icons, but are in reality on "About" dialogs. TinyMCE actually labels theirs "Help", while CKEditor's is at least labeled with a title of "About" to match its real purpose. It might be helpful to add a link to real end-user documentation for the editor here. I'm assuming that a screen reader user could access the toolbar controls with something like a links list or form controls list dialog, but a strict keyboard only user would still need a way to navigate to it or have an easily accessible help link.

I created a site on Sakai 3's demo server (at http://3akai.sakaiproject.org/dev/index.html), and noticed it uses TinyMCE to edit the site's content. The toolbar is configured as an external toolbar and has been customized. I couldn't get the access key as published on TinyMCE's site to give access to the toolbar on the Sakai 3 site using Firefox on either my Mac or PC. So keyboard access seems to be broken in that implementation, but I might be missing something! The implementation in the Sakai 3 demo is configured to allow switching between the WYSIWYG view and an HTML editing view.

I haven't read the developer's documentation on either editor, but it seems that from the variation I've witnessed between various implementations of the editors and in the demo examples that the accessibility of the editor is affected by the implementation/configuration used by the developers.

In Michael Korcuska's requirements documentation at (http://docs.google.com/View?docid=ddx8d6kd_14hkxrgsgm&hl=en) there is a detailed requirements section which outlines the must haves for the text editor. I find it hard to tell a given document I find is current, but this one includes that "The editor should be WYSIWYG as much as possible, including occupying the approximate screen real estate that the content will occupy when users view the page" as a "must have". The WYSIWYG editors mentioned appear to be configurable such that they can toggle between the WYSIWYG editing mode and a text-only (html, wiki, etc.) mode. It seems that in either mode, to create formatted documents with features like bold, italics, headings, lists, tables, etc. a learning curve and user skills would be required. How the editor is implemented, and exposing meaningful end user documentation seems key to the success of how accessible it will be in the end. If the editor included a feature such as a paste-from-word function that retained formatting, or otherwise allowed for the upload of content created by the user into the editor then the user could use an editor on their desktop that they find more accessible and are already familiar with.

I imagine there are many technical concerns over choosing an editor to replace the fckEditor as well. For instance, how compatible is the new editor with rendering and editing the already existing content?

-Brian
________________________________________
From: kennpetri at gmail.com [kennpetri at gmail.com] On Behalf Of Ken Petri [petri.1 at osu.edu]
Sent: Wednesday, November 11, 2009 6:22 PM
To: Richwine, Brian L
Cc: Sakai Accessibility WG
Subject: Re: [WG: Accessibility] [Management] Fwd: Sakai 3 Capabilities and     Accessibility

Adding to implementations, an editor that does wiki, markdown, and textile is Jay Salvat's MarkItUp (). It is interesting in particular because it provides set of keyboard shortcuts and buttons for generating these syntaxes, thereby reducing the learning curve.

As to the CK v. Tiny debate: It was mentioned in another thread that it might be worth Sakai revisiting the choice of Tiny. The points from Brian, Joe, and Mary, and Margaret's investigation are well-taken. Still, in a head-to-head, I'm not sure Tiny fairs much better, and may fair worse. For example, the implementation of drop-downs in Tiny is no better and often much worse and the "tab through toolbar controls" metaphor that Tiny uses is less true to a desktop WYSIWYG than the "arrow key" approach CK takes. The problem that CK has with not telling the user how to get to the toolbar controls can be overcome with a small bit of text announcing the functionality.

The point may be moot, though, if you decide to go with the recommended "user chooses" model of text-based/markdown/textile/wiki or WYSIWYG or upload.

My two cents,
ken
----


On Fri, Nov 6, 2009 at 2:59 PM, Richwine, Brian L <brichwin at indiana.edu<mailto:brichwin at indiana.edu>> wrote:
> Is Markup known as the dominant
> syntax in the world of accessible
> editors, or was it just an example?

In our experience, there isn't a dominant syntax for an accessible markup language, nor is there a dominant accessible WYSIWYG/GUI/Rich Text Editor.

The conversation seems to be running between choosing a single "accessible" editor, or providing a choice of editor and/or upload option. The answer seems larger than just the accessibility concerns, but concerns of both usability and product design specification as well. A well designed user experience study to test between the usability of the WYSIWYG editors and the text-based/wiki style editors would yield important information to aid in making the decision. Obviously there are other concerns (technical, user feature requests,...), but as there doesn't seem to be a consensus in the community we think such a study would be of value.

If it was seen as valuable, the ATC is happy to help with performing such a usability study and welcomes others to help.

Are current feeling is that having both editor options (WYSIWYG and text-based) along with the option for uploading content is best.


-Joe Humbert, Margaret Londergan, Brian Richwine, Mary Stores

Adaptive Technology and Accessibility Centers
Indiana University - Bloomington/Indianapolis
http://iuadapts.indiana.edu
(812) 856-4112



-----Original Message-----
From: accessibility-bounces at collab.sakaiproject.org<mailto:accessibility-bounces at collab.sakaiproject.org> [mailto:accessibility-bounces at collab.sakaiproject.org<mailto:accessibility-bounces at collab.sakaiproject.org>] On Behalf Of John Norman
Sent: Friday, November 06, 2009 11:21 AM
To: Michael S Elledge
Cc: management; pedagogy Learning; Sakai Accessibility WG
Subject: Re: [WG: Accessibility] [Management] Fwd: Sakai 3 Capabilities and Accessibility

I'm out of my depth here, but does the TinyMCE example 9 (implementing
BBCode syntax) indicate a way forward? I confess I had never heard of
markdown, so I Googled TinyMCE and Markdown to find:
http://www.sitepoint.com/forums/showthread.php?t=590572
Then Wikipedia on Markdown
http://en.wikipedia.org/wiki/Markdown
Which led me to a JS implementation, Showdown:
http://attacklab.net/showdown/

So now I have the idea that Markdown is both a syntax and an editor
and the editor stores information in non-html form. This seems to be
very similar to using wiki markup and I found this page on lightweight
markup which suggests MediaWiki syntax and BBCode are in the same family
http://en.wikipedia.org/wiki/Lightweight_markup_language

Armed with this picture of what Mike may be suggesting, I get to his
question: Do we know how often a rich text editor is used and needed?

My response is based on the Wiki in Sakai 2. We discussed (and even
did proof of concept) for inserting gadgets into wiki pages. The main
reason we chose to use TinyMCE instead, was the preponderance of
Faculty demand for WYSIWYG *or* html editing. Comments like "why are
you making me learn some new markup, when I know html?" and "why can't
I just edit it like a word document?" were common. There were only a
few who expressed "I encourage students to learn Wiki markup because
it is useful for them to know how Wiki's work". Now of course, Wiki
markup was available so you wouldn't expect many requests for it, but
it seems (anecdotally) like a minority sport.

My guess would be that if BBCode can be supported in TinyMCE (now that
I know Markup is lightweight markup, like BBCode) then that would be
the easiest way to go. I imagine that we will need to do work to
implement the extensions/plugins we have used to insert gadgets in the
page. And it seems like an important choice might be: which
lightweight syntax to implement? Is Markup known as the dominant
syntax in the world of accessible editors, or was it just an example?

Sorry for taking you through my ignorance, but I thought it might be
useful for fellow novices. Corrections welcome.

John

On 6 Nov 2009, at 15:27, Michael S Elledge wrote:

> Hi Eli (and everyone)--
>
> It sounds like providing a text-based editor (with markdown or wiki
> markup) and using TinyMC as the rich text editor (rather than
> CKeditor) is the way to go, per our conference call yesterday on
> accessibility, Indiana University's testing and John Norman's
> comments about Sakai 3 plans (to replace FCK with Tiny).
>
> I wonder if we shouldn't make the text-based editor the default,
> with rich text editing the option, instead of the other way around.
> Do we know often a rich text editor is used and needed?
>
> What do you think?
>
> Mike
>
> Daphne Ogle wrote:
>> On Nov 5, 2009, at 9:10 AM, Eli Cochran wrote:
>>
>>
>>> But really, all we really need are simply stated accessibility goals
>>> for Sakai 3.
>>>
>> We started a new sheet for usability/design goals.  They aren't
>> pedagogical goals yet in discussion we felt we didn't want lose
>> the  ideas.  I think accessibility goals would fit nicely on that
>> sheet too.
>>
>> -Daphne
>>
>>> - Eli
>>>
>>>
>>> On Nov 4, 2009, at 10:34 AM, kamann at stanford.edu<mailto:kamann at stanford.edu> wrote:
>>>
>>>
>>>> Hi,
>>>> I was on the T&L call where people were talking about this Learning
>>>> Capabilities matrix
>>>> https://spreadsheets.google.com/ccc?key=0AlfbHxo2qpHEdHRuSnowVGMwWE9HY1MtVjFpY1dtS0E&hl=en
>>>>
>>>> Clay sent a notes saying the list started out around learning and
>>>> teaching goals, but there were a few entries that jumped ahead to
>>>> the technnology like "Allow me to listen to class readings with a
>>>> screen reader." This was written from the perspective a persona
>>>> from
>>>> the Fluid project with low vision. We were struggling with what the
>>>> goal during the call and I'm not sure we got there, but we knew her
>>>> goal wasn't to use a screen reader. On further reflection, the
>>>> visually impaired student's goals here is the same as any other
>>>> student:
>>>>
>>>> "Easily review class readings and materials"
>>>>
>>>> This is actually not yet a row in the list, but I'll add it --
>>>> perhaps the accessibility considerations should be called out as an
>>>> additional column?
>>>>
>>>> I mentioned that this reminded me of another thread from the
>>>> management list -- it's posted below. Nate Angell, in response I
>>>> believe to John Norman's Manifesto for Grading and Rating, began a
>>>> list of what he's also calling "capabilities" such as
>>>> accessibility,
>>>> discoverability, searchability, and tagability
>>>>
>>>> http://wiki.sakaiproject.org/display/MGT/Sakai+3+Capabilities
>>>>
>>>> These capabilities seem more like technological principles that cut
>>>> across at right angles to the list that T&L is putting together--
>>>> that is, that the way these learning capabilities will manifest
>>>> themselves will be by employing these general principles, that Nate
>>>> has started to outline. That may be overly simplified, but it kind
>>>> of looks that way.
>>>>
>>>>
>>>> Keli
>>>>
>>>> ----- Forwarded Message -----
>>>> From: "Eli Cochran" <eli at media.berkeley.edu<mailto:eli at media.berkeley.edu>>
>>>> To: "Nate Angell" <nate.angell at rsmart.com<mailto:nate.angell at rsmart.com>>
>>>> Cc: management at collab.sakaiproject.org<mailto:management at collab.sakaiproject.org>, "sakai-dev Developers" <sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org>
>>>>      Sent: Monday, November 2, 2009 9:22:10 AM GMT -08:00 US/
>>>> Canada  Pacific
>>>> Subject: Re: [Management] Sakai 3 Capabilities
>>>>
>>>> Nate,
>>>> Very helpful. I love the idea of having it all in one place.
>>>>
>>>> At first I wanted to pull some of the items like "accessibility"
>>>> and
>>>> "rights and permissions" into their own list. They seem
>>>> different  than
>>>> functionality that specifically supports teaching and learning.
>>>>
>>>> But the more I think about it the more I like the one list to rule
>>>> them all. It supports the idea that most of these concepts should
>>>> be,
>>>> like "Grading/Ranking/Rating/Reviewing/Evaluating", pervasive and
>>>> omnipresent -- baked in everywhere -- in the same way that
>>>> accessibility should be baked in everywhere and supported by the
>>>> underlying architecture.
>>>>
>>>> Thanks,
>>>> Eli
>>>>
>>>> On Oct 28, 2009, at 2:38 AM, Nate Angell wrote:
>>>>
>>>>
>>>>> Like many of you, I've been frustrated by my ability to put my
>>>>> head
>>>>> around the conversations and intersections around Sakai 3.
>>>>>
>>>>> After a conversation with Clay, I decided to put together a
>>>>> stab  at a
>>>>> wiki presentation of a Sakai 3 dashboard that might help us
>>>>> organize
>>>>> and better understand our work.
>>>>>
>>>>> Accordingly, I've posted the bones of an example below, where I've
>>>>> begun a list of capabilities already under discussion for Sakai 3:
>>>>> http://wiki.sakaiproject.org/display/MGT/Sakai+3+Capabilities
>>>>>
>>>>> And I began to flesh out one example capability: Grading:
>>>>> http://wiki.sakaiproject.org/display/MGT/Gradability
>>>>>
>>>>> Still missing from Gradability are examples of actual (user)
>>>>> experiences and technologies used to deliver this capability.
>>>>>
>>>>> There are at least a couple of limitations I see already to this
>>>>> format, but I'm open to suggestions and modifications:
>>>>>
>>>>> 1) Sakai 3 work is highly relational, yet it's handy to see
>>>>> material
>>>>> in context. I already found myself cutting and pasting material
>>>>> that
>>>>> might appear in more than one place.
>>>>>
>>>>> 2) The wiki format doesn't allow a preview of the "card" format,
>>>>> yet
>>>>> the card format allows chunks of info to surface at the top of the
>>>>> page.
>>>>>
>>>>> --
>>>>> Nate Angell
>>>>> Client Evangelist
>>>>> @xolotl = twitter
>>>>> http://www.rsmart.com
>>>>>
>>>>> _______________________________________________
>>>>> management mailing list
>>>>> management at collab.sakaiproject.org<mailto:management at collab.sakaiproject.org>
>>>>> http://collab.sakaiproject.org/mailman/listinfo/management
>>>>>
>>>>> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org<mailto:management-unsubscribe at collab.sakaiproject.org>
>>>>> with a subject of "unsubscribe"
>>>>>
>>>> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
>>>>
>>>> Eli Cochran
>>>> user interaction developer
>>>> ETS, UC Berkeley
>>>>
>>>>
>>>> _______________________________________________
>>>> management mailing list
>>>> management at collab.sakaiproject.org<mailto:management at collab.sakaiproject.org>
>>>> http://collab.sakaiproject.org/mailman/listinfo/management
>>>>
>>>> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org<mailto:management-unsubscribe at collab.sakaiproject.org>
>>>> with a subject of "unsubscribe"
>>>> _______________________________________________
>>>> management mailing list
>>>> management at collab.sakaiproject.org<mailto:management at collab.sakaiproject.org>
>>>> http://collab.sakaiproject.org/mailman/listinfo/management
>>>>
>>>> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org<mailto:management-unsubscribe at collab.sakaiproject.org>
>>>> with a subject of "unsubscribe"
>>>>
>>> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
>>>
>>> Eli Cochran
>>> user interaction developer
>>> ETS, UC Berkeley
>>>
>>>
>>> _______________________________________________
>>> accessibility mailing list
>>> accessibility at collab.sakaiproject.org<mailto:accessibility at collab.sakaiproject.org>
>>> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>>>
>>> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org<mailto:accessibility-unsubscribe at collab.sakaiproject.org>
>>>   with a subject of "unsubscribe"
>>>
>>
>> Daphne Ogle
>> Senior Interaction Designer
>> University of California, Berkeley
>> Educational Technology Services
>> daphne at media.berkeley.edu<mailto:daphne at media.berkeley.edu>
>> cell (925)348-4372
>>
>>
>>
>>
>> _______________________________________________
>> accessibility mailing list
>> accessibility at collab.sakaiproject.org<mailto:accessibility at collab.sakaiproject.org>
>> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>>
>> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org<mailto:accessibility-unsubscribe at collab.sakaiproject.org>
>>  with a subject of "unsubscribe"
>>
>>
>>

_______________________________________________
accessibility mailing list
accessibility at collab.sakaiproject.org<mailto:accessibility at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/accessibility

TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org<mailto:accessibility-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"
_______________________________________________
accessibility mailing list
accessibility at collab.sakaiproject.org<mailto:accessibility at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/accessibility

TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org<mailto:accessibility-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"

More information about the accessibility mailing list