[WG: Accessibility] [Management] 2.7.0: FckEditor upgrade to CK3.0.1

[Hadi Rangin]

Hello,

 

I have been a member of this list for several years and have been following most of your discussion. I commend you all who have been working on improving the usability/accessibility of SAKAI.

 

I have never used SAKAI, not even seen the interface yet but I am pretty sure that it is a complicated application similar to Blackboard/WebCT or Desire2Learn. As some of you know we have been working with Blackboard/WebCT for number of years and trying to improve their accessibility/usability. Ken Petri is also working with Desire2Learn to achieve the same and I am helping them a little bit too.

The latest versions of these two products support significantly more accessibility features and I am pretty sure that SAKAI is becoming more accessible from one version to another too.

 

While using the Web is a great method to access complicated application such as Learning Management Systems but unfortunately despite all the effort to make them accessible, such application remain very difficult to use for people with disabilities in particular blind.

 

We might not have necessarily the same understanding about accessibility. Some people tend to focus on only technical accessibility and forget to see the big picture if the application as a whole is usable to users with disabilities. The technical reason for this problem is that both the application layer and the content layer are rendered in HTML. It means that a screen reader user has to use the same navigation mechanism to move in the application and in the content and interact with it. For example, we have to use the same technique to get to a link in the application menu and trigger it as a link in the content area. Of course, visually, you can easily skip the application layer all together and trigger the desired link in the content area but a screen reader user doesn't have any chance to do it. ARIA can ease the navigation if it is used properly but it is still not sufficient.

 

One of the major problems that I see in the rich applications is the lack of customization of the applications and their components. Improving the customization of an application will definitely improve its usability and accessibility. I think every user should be able to customize all non-essential modules and their options.

 

Let us look into the CKEditor example: Assuming CKEditor was fully accessible, I probably need only 5-8 HTML tags for standard editing whereas you might need 40 of them. Why do I have to go through all the tags that I absolutely know that I am not going to use?

If it was user configurable, then I could choose my 5-8 tags and you could do your 40 tags and everyone would be happy and could work more effectively with our customized interfaces.

 

The same thing applies to the accesskeys that I see it is being discussed on this list for some time. First, please do not consider accesskeys as a life-saver. Assuming there is no conflict between the OS, browsers, and assistive technology on the accesskeys, they are only useful if they only a few (1-5) and are used consistently across an application for repetitive functions. They are no longer useful if they change from one page to another.

 

Here again, I believe all accesskeys should be customizable so everyone can customize them based on the availability of the accesskeys in their systems.

 

Regarding the using Wiki-style markup vs. full-fledge rich editor, I think the problem here is to choose between bad and worse. I think a full-fledge rich editor is a better choice if they were *practically* accessible. I think this would make the portability of the course content a lot easier. But what can we do when they are not accessible? At least a Wiki-style editor would give me to get the job done independently within a reasonable time.

 

I would be delighted to participate in one of your future teleconference to discuss it further if you prefer. I think it would be also great if Ken petri can join such discussion too.

 

Thanks,

Hadi



 ----- Original Message ----- 

  From: Ken Petri 
  To: Eli Cochran 
  Cc: Hadi Rangin ; management at collab.sakaiproject.org ; Sakai Accessibility WG ; Clay Fenlason 
  Sent: Tuesday, November 03, 2009 11:31 PM
  Subject: Re: [WG: Accessibility] [Management] 2.7.0: FckEditor upgrade to CK3.0.1


  Hi Eli,

  I think Hadi is the best one to address this. He is screen reader reliant. I just use them for testing. 

  However, in my experience you gain two things from a markdown/textile/wikitext form of input: 1) Since you are working with just text, there are no UI complications for either screen reader or keyboard-only users, and 2) End users are much more conscious of what they are doing in terms of the semantics of a page and, if your parser is good, you can guarantee perfect HTML output (outside of HTML intentionally included by end users).

  Hadi has worked closely with systems that take wikitext/textile input for HTML rendering. He is also a very experienced developer.

  Best,
  ken



  On Tue, Nov 3, 2009 at 3:05 PM, Eli Cochran <eli at media.berkeley.edu> wrote:

    Ken,
    I'm curious about your recommendation. Is your experience that the overhead and complexity of navigating rich text controls with the keyboard makes it more appealing to screen reader users or keyboard users to use a wiki-style markup language instead? It actually makes a lot of sense to me, but I'd never really thought about it, nor have I heard this before.


    Thanks,
    Eli 


    On Nov 3, 2009, at 10:31 AM, Ken Petri wrote:


      Though I'm not involved in the Sakai Access WG except as a lurker (and now a poster, I guess), my ultimate recommendation would be to offer an option to use Textile or WikiText or Markdown or some similar text based/interpreted for content editors.



    . . . . . . . . . . .  .  .   .    .      .         .              .                     .


    Eli Cochran
    user interaction developer
    ETS, UC Berkeley





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/accessibility/attachments/20091106/348b298a/attachment.html