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

Fri Nov 6 09:47:53 PST 2009

Hi:

 I don't often post to this list but I felt as a 4 year user of sakai that
is blind I could reply. 

Having  a widely used tool like this be as customizable as you suggest is a
bad idea. if a student moving from one member campus to another does not
find a constant interface in the product, it may cause some students to lose
their ability to use the product.  The difference between sakai and web ct
and black board is that sakai was built from the beginning with
accessibility as a main strength. Yes the interface at times may seem hard
but it is not a accessibility problem all parts of sakai  were designed to
be accessible and are tested to be sure of that before release. This group
does a fantastic  job of keeping the access issues to the front of the
development. As a person that works with students with learning disabilities
I vote for not making it an end-user customizable interface but a interface
that grows as it is to be easier to use every release. 

 Lucia Greco

Assistive Technology Specialist 

UC Berkeley, Disabled Students Program

(510) 643-7591

http://attlc.berkeley.edu

From: accessibility-bounces at collab.sakaiproject.org
[mailto:accessibility-bounces at collab.sakaiproject.org] On Behalf Of Hadi
Rangin
Sent: Friday, November 06, 2009 9:14 AM
To: petri.1 at osu.edu; Eli Cochran
Cc: management at collab.sakaiproject.org; Sakai Accessibility WG; Clay
Fenlason
Subject: Re: [WG: Accessibility] [Management] 2.7.0: FckEditor upgrade to
CK3.0.1

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 <mailto:petri.1 at osu.edu>  

To: Eli Cochran <mailto:eli at media.berkeley.edu>  

Cc: Hadi Rangin <mailto:hadi at illinois.edu>  ;
management at collab.sakaiproject.org ; Sakai Accessibility WG
<mailto:accessibility at collab.sakaiproject.org>  ; Clay
<mailto:clay.fenlason at et.gatech.edu>  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/11fec366/attachment-0001.html 