|
»
Re: [WG: Accessibility] [Management] 2.7.0: FckEditor upgrade to CK3.0.1
|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
|
|
|
Re: [Management] [WG: Accessibility] 2.7.0: FckEditor upgrade to CK3.0.1
by Noah Botimer
::
Rate this Message:
I think this is the right question. ("Does the choice really matter
now or is it more important that we have made a choice?") I have some specific thoughts about the CKSource/Moxiecode debate, but will spare them for now. What I will say in my typical diffusive fashion is... Google has released their "Closure Library" today, which includes their rich text editor: http://googlecode.blogspot.com/2009/11/introducing-closure-tools.html http://code.google.com/closure/library/docs/introduction.html It looks like everything is licensed Apache 2.0. By the way, this also includes the "seamless editor" mode that made Page Creator so attractive to me. I have been waiting for this for two years and will definitely be researching it. Thanks, -Noah On Nov 5, 2009, at 7:05 AM, John Norman wrote: > Excellent work, thanks. > > A particular interest of mine surounds the comparison between CK > Editor and TinyMCE. We chose to work with TinyMCE in Sakai 3 largely > because of its reputation for handling accessibility issues (but also > because of its plugin support). Is there anything in this new CK > Editor release that would suggest we need to revisit that decision, > bearing in mind that it might require a _lot_ of work? But if the > signs are there we should pay attention. Presumably TinyMCE will be > continuing to develop and we may just be seeing normal technology > leap- > frogging in action. > > cc'ing Fluid in case they have any insights... > > Best, John > > On 4 Nov 2009, at 19:20, Humbert, Joseph A wrote: > >> Hello, >> >> The web accessibility team at the Adaptive Technology and >> Accessibility Center has performed scenarios to test the usability >> and accessibility of the new CK Editor using the accessibility >> documentation found at http://docs.cksource.com/CKEditor_3.x/ >> Accessibility >> . We believe that while the CK Editor is more accessible than the >> FCK Editor currently being used for Sakai, there are some >> improvements that need to be made to increase the accessibility of >> the editor and be more in conformance with WCAG 2 guidelines. Below >> is a list of issues, along with suggestions for improvement of the >> editor and documentation. >> >> The reason the CKEditor is a step forward is because in previous >> versions of FCK Editor, the only way for students using a screen- >> reader to submit assignments was to upload a Word (or some other >> file type) document. Screen-reader users could not access, for >> example, the font options if a professor wanted the assignment in 12- >> point Times New Roman. With the CKEditor, though, screen-reader >> users can type or paste their assignments in the editor, adjust >> fonts, make words bold, italic, etc. >> >> Regarding the documentation about using JAWS with the editor: >> >> · “JAWS Editing Mode vs. Non-Editing Mode” – this is >> actually called Forms Mode. >> · No mention is made, that I can find, of the version of >> JAWS this documentation was written for. Starting in version 10 the >> high-pitch pop sound indicates that the user can start typing text; >> there is no need to press Enter to activate the edit mode because >> JAWS now detects the need to do this automatically (unless the JAWS >> user has the auto-forms mode setting turned off). >> · The CKEditor’s tools list, which can be accessed by >> pressing Alt+F10, can also be accessed with the JAWS screen reader >> using the JAWS links list dialogue, Insert+F7. In addition, no >> mention of the JAWS Forms List dialogue, Insert+F5, is mentioned, >> which is the easiest way to get to the edit field where text can be >> written. >> >> We would be happy to rewrite the JAWS documentation so that JAWS- >> specific keystrokes are mentioned for easier navigation. >> >> Improvements to Enhance Accessibility of the Editor: >> >> · All form fields should be labeled. The initial edit field >> of the editor itself (where the user inputs text), as well as all >> resulting form fields that the user can create in their document >> (when, for example, selecting a radio button), are not labeled. >> There is also no option for the user to create accessible form >> fields. >> · The frames for the different components (the editor, the >> spell check dialog, etc.) need better labels. For instance, when >> JAWS users utilize the frames list dialog while spell checking, >> titles such as “mid” and “bot” do not make sense. >> · The various fields that appear in the CKEditor’s dialog >> boxes are not labeled (ie: spell checker, defining radio buttons, >> etc.). >> · The “Drop down boxes” on the CKEditor’s toolbar are not >> announced as dropdown boxes by a screen reader when selected. There >> should be actual drop down boxes instead of links that use scripting >> to emulate dropdown boxes. >> · To screen reader users, all tools in the CKEditor tool bar >> appear as links on separate lines (with blank lines between >> groups). These should instead appear in lists and nested lists for >> easy navigation by screen-reader users. JAWS users can press l and i >> to jump to lists and list items. Screen-reader users will then be >> able to understand how many items are in each list and their >> relation to one another, e.g., styles, format, font, font size, text >> color and background color are all related. >> · The dialog boxes for the CKEditor (like when creating a >> radio button) appear at the bottom by the page when activated using >> JAWS. When the tool’s link was first clicked, it appeared as if >> nothing happened. We had to search the page to find that the dialog >> box’s content had appeared. An anchor tag and appropriate scripting >> should be added so when the dialog opens focus can be given to the >> anchor tag where the dialog box’s content is located. >> · The CKEditor’s toolbar isn’t easily accessible to keyboard >> only users. When the keyboard user navigates into the editor, focus >> immediately jumps to the content area, skipping the tool bar. The >> normal tab/arrow key navigation cannot be used to access the >> toolbar. It isn’t immediately obvious (because instruction to do so >> isn’t given on the page) that the keyboard only user needs to press >> Alt+F10 to get into the toolbar (After pressing Alt+F10, then the >> keyboard user can arrow through the toolbar’s controls). >> · A keyboard accessible link needs to be provided that lists >> the access keys and other necessary user documentation for using the >> editor. >> >> This is only a summarization of the testing we did and the issues we >> found. We would be happy to write a more detailed report explaining >> the protocol we used to do the testing and the scenarios we >> performed. We would also be very happy to discuss these issues and >> any questions you might have at the Sakai Accessibility Working >> Group teleconference which is tomorrow November 5, 2009 at 2 PM >> Eastern time. The phone number is (812) 856-3600 and the PIN is >> 002264#. All are welcome to attend. >> >> Web Accessibility Team >> UITS Adaptive Technology and Accessibility Centers >> >> Joe Humbert Mary Stores Brian >> Richwine Margaret Londergan >> johumber@... mstores@... >> brichwin@... londerga@... >> Office 317-274-4378 Office 812-856-2760 Office >> 812-856-2757 Office 812-856-2763 >> >> From: accessibility-bounces@... >> [mailto:accessibility-bounces@...] On Behalf Of >> Ken Petri >> Sent: Wednesday, November 04, 2009 12:32 AM >> To: Eli Cochran >> Cc: management@...; Sakai Accessibility WG; Clay >> Fenlason >> 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@...> >> 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 >> >> >> >> _______________________________________________ >> accessibility mailing list >> accessibility@... >> http://collab.sakaiproject.org/mailman/listinfo/accessibility >> >> TO UNSUBSCRIBE: send email to accessibility- >> unsubscribe@... >> with a subject of "unsubscribe" > > _______________________________________________ > management mailing list > management@... > http://collab.sakaiproject.org/mailman/listinfo/management > > TO UNSUBSCRIBE: send email to management- > unsubscribe@... with a subject of "unsubscribe" > > _______________________________________________________ fluid-work mailing list - fluid-work@... To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work |
| Free embeddable forum powered by Nabble | Forum Help |
