Author: jku@illinois.edu

Date: July 13, 2016

Location: Engineering Library, Room 329

Attendees:
Jon Gunderson, Nick Hoyt, Robert Slater, Mike Scott

Meeting Goals

Come up with feature documentation for three components – heading, list, and images.

CKEditor is oriented towards people who have some knowledge of HTML markup and how the editor wants something to look. OneNet takes the focus away from how things are going to look/markup, and focuses on semantics.

Conceptual Model defined: The main objects and actions, and their relationships in a system.

Main problem with the horizontal toolbar is limited real estate tends to lean towards graphical buttons without text/descriptions to lead people to the correct/best semantic choice.

Front load/emphasize all semantic-based choices in the editor.

Keep a format/formatting section (not sure what it should be called), but limit it to simple formatting (strong, emphasis, line break, etc). Also have a section (templates or special objects maybe) for advanced/custom objects.

Is it possible for us to present a vertical editing menu for the WYSIWYG, and if so, is it desirable (with regards to integration of the editor into CMSes like WP)?

Conceptual Model

Main Objects

• Document (implicit)
• Parent blocks of text
  • Heading
  • Paragraph
• Children of parent blocks of text
  • Strong
  • Emphasis
  • Links
    • External
    • Internal
    • In page fragment identifiers
  • Templated objects (custom)
• Compound blocks of text
  • Tables
  • Lists
  • Templated objects (custom)
• Images/applets/objects

Main Actions

• Typing text (primary action): inserts characters into some element
• Hitting enter/return: inside a block, splits it; at the end of an element, closes block and opens new one
• Selecting text/content
• Insert (the structure for) a block of text of some type: paragraph, list, etc.
• Change the type of an element (change of the block level element type, e.g. paragraph to heading)
• Changing the format of selected content (inline change, within a block level)
• Change the “table template” for presentation of a table/types of data tables
• Change the heading formatting (at the overall page level, not the individual headings)

Functional Requirements

Date: July 19, 2016

Agenda: Lists, Links, Tables

Lists

1. Provide an obvious means of formatting current blocks of text as lists/list items. Functionality: Provide a ‘list’ menu that is prominent/obvious that includes CSS standard style types (bullet styles, numbering, etc.)
   1. Also need to support list-style: none (could provide template for something like citations)

Date: May 25, 2016

Location: University Library, Room 225B

Attendees:
Hoyt, M Nicholas‎; Gunderson, Jon R‎; Slater, Robert‎; Weathers, William Fletcher‎; Scott, Mike; Colin Fulton‎‎; Coombes, Katelyn Michelle‎; Robert (BJ) Moore; TJ Schlouski

Meeting Topic

Currently the OneNote editor works only in Internet Explorer. The goal is to make it cross-browser compatible.

The first goal is to get the general idea of the current version of OneNet. Find out what needs to happen to make it a stand alone plug in, capable of replacing CKEditor or TinyMCE. We should also think about what needs to change in the code to make it usable in other browsers.

The second goal involves considering the project from an architectural standpoint. What would it take to merge OneNet’s functionality into one or both other editors (CK/MCE)? Since the other editors already have a large user base, going this route could make integration more convenient. However, important to keep in mind that a lot of OneNet’s strengths stem from the fact that it was built from the beginning with user accessibility in mind.

Proposals

1. Document the features/functional requirements to achieve OneNet’s goals. This makes it possible to line up what we want with what we can achieve.
2. Take a look at OneNet code, as well as the CK editor and TinyMCE.
3. The biggest challenge with integrating is that some of the key features of OneNet occur as content is created.
   1. (Colin) Integration is not impossible, simply more difficult.
   2. (JaEun) Note that the CK accessibility checker prompts in real time.
   3. (Colin) We could possibly that other editors and simply tweak them a little bit. The biggest concern with this is that these editors are not necessarily cross browser.

Considerations

• One option for the project is to take the OneNet approach and build from the ground up.
• However, we could also look at open source accessibility tools. For example, collect information about when people accept prompting to change versus deciding to ignore the prompting.
• A relevant concern is that multi-media and video capabilities are the biggest thing missing from OneNet now.
• Suggested thoughts/actions from examining OneNet source code:
  • Perhaps consider what would it take to build additional desirable features?
  • Make a list of what is not covered by existing OneNet editor. We could see what we like in OneNet, and then make a matrix to compare what current tools do (CKEditor/etc.).
• Another problem to consider: Is it possible to make the new editor proactive?
  • Note that not all people will accept these restrictions (especially in University conditions). Important to make sure make people still feel like they have choices/control.
  • To address this, potentially make it have a similar user interface look to others. Most administrators only see appearance rather than function (see controls).
• Another potential attractive option is that if possible we could use base (CK/MCE) and then build user interface on top of it.
• Measuring stick when evaluating the new web editor is whether it is as accessible as Microsoft Word.

Priority List

1. Help people author accessible stuff. This will have the biggest impact, and is the primary goal of the project.
2. Make the actual interface accessible. This should be made possible when it can reasonably be done. This is still a real issue, but not the mission of this particular project.
3. Important to note that whatever method we pick, we need to make sure it doesn’t shut the door on working on Priority 2 in future projects.

Deliverables

General:
1. Document the features/functional requirements to achieve OneNet’s goals (lining up what we want with what we can achieve). Make a shared document which can be edited and accessed by all.
2. Examine Content Editables and find out general opinions.

Specific:
Mike = will start the shared draft; also examine content editables
Jon = consult people who may know about Wiziwig accessibility/content accessibility
Colin = look closer at what CK/TinyMCE custom stuff is doing; some general investigation
Nick = research more about content editables; add to shared document

Next meeting is June 8th, at 2-4 p.m.

Date: May 12, 2016

Location: University Library, Room 225B

Attendees:
Ku, JaEun; Prom, Christopher John‎; Chapman, Suzanne E‎; Weathers, William Fletcher‎; Hoyt, M Nicholas‎; Gunderson, Jon R‎; Coombes, Katelyn‎; Scott, Mike; Lane, Lori; Kate Coombes (Scribe)

Meeting Theme:
Investigate and take note of any existing text editor components which can ensure better accessibility.

Presentation (40 min)

Mike Scott’s presentation: A report on the experiences of the Department of Human Services trying to create an accessible content management system and editor; started over ten years ago.

1. Introduction

• Background of Problem: Originally all content was recoded by technical folks (from the work of ordinary users) before it was put up; then extra needed to not only put content up but keep it accessible (bottlenecks). They were looking for ways to augment the process.
• Solutions: Website content management system. Thousands of pages, hundreds of non-technical editors. Room for improvement but overall success.
• Mike took us to the Illinois Dept of Human Services site and used the Accessibility of Test and Examples (Sample Page) to show how it worked.
• Following rules from IITAA; requires all state entities to keep electronic information accessible (not much different from federal/international standards); goal was to do this as easily and efficiently as possible (alternate text for images, headings to identify structures, other HTML markups correctly (lists), indicating headers in tables).
• Allow for increasing number of web authors.

2. Site Editing Demo Using OneNet Text Editor

• Headings/List/Link/Images/Document/Table/Columns/Format/Check (All text editor menu list on side.)
• Showed us the concerns with moving (copying/pasting) Word documents; the editor can have difficulty interpreting that, so it will often get rid of the proper header settings. Many web authors without backgrounds in accessibility will not use the headings properly.
• Combination of proactively providing tools they want web creators to use (example: put heading sizes in order of use) the editor also prompts them to do the most accessible display option (NOT put headings in regular text but in bold). Explanations for these prompts are provided, but it is assumed most people do not read them.
• Pages within the site can be easily linked to. Mike makes a point to show that links should be understandable out of context as much as possible to assist screen readers. Avoid using ambiguous links (“Click here!”). Editor will prompt (sometimes actively prevent, but not always) to keep with accessibility compliance.
• Only certain users can upload images into library, more people can access and use those images.
• Images include alternate text options based on whether the image is decorative (optional), simple, or complex. The latter two require a short explanation of what the image is about without actually having to see graphic. Usually between 1-20 word explanation.
• Will prompt users to create accessible/link to accessible version of a linked document (potential to contact to make accessible/is accessible).
• Tables
  • Tables need to be marked up to be accessible (such as headings). Web author can either make the table or post the table from Word document (interpreted through editor). Multiple words within a table are fine (only new line character/tab character throw it off); tables can have multiple headers.
  • If something seems too complex when pasting, the editor will let you know there may be issues when trying to format it into the table; may have to manually make corrections. Issues with merge/split – only can merge in an accessible way.
  • Light background shading on table to show what is heading. Wanted to allow some complexity in creating tables while still being able to provide codes behind table to make it still accessible. Most users do not see html option (only approved users with enough tech skills); see html code changes behind table.
  • Columns is a way to format multiple columns without needing tables (allow up to 5 of varying widths).
• Project Report on this text editor, 2006: tried to test ability of creators to make web accessible content; tested with different tools such as OneNet text editor, Microsoft Word, Microsoft FrontPage, Macromedia Contribute.  The study scored how well they did. Conclusion: OneNet, “Accessibility First” Prototype achieved accessibility of 72.3%, while other tools such as Microsoft Word, Microsoft FrontPage, Macromedia Contribute did 31.2% only.
• Project Primary goal was make accessibility “automatic” as you go.
• People didn’t use checkers as-you-go in other tools.
• Checkers in editor = force run whenever users go to publish; if they see relevant elements they bring up checkers; start with explanations and instructions/warnings (not actual headings used, just bold text); makes changes in checker screen which automatically change in document. Warns: same page linked with different texts.

3. Q and A

• Question (JaEun): is it OneNet text editor’s functionality to strip out MS Word tag when it is copied to OneNet text editor? Answer: The OneNet text editor intercepts paste command and works from clipboard; pulls info from clip board/analyze/strip/mark up.
• Question (Jon): How much of this functionality is part of being in IE and how much can be done in other browsers? Answer: Most of it standard JavaScript and not relying on IE proprietary functions. Would take some work to change in other browsers, but not impossible.
• Mike: OneNet is open source; wants to move from html1 to html5; possibility of collaboration between University and state to update code/within whatever content management system (separate the editor and content management system), though challenge to /use in other browsers.
• Mike: Potential for time/state funding.
• Group was impressed with checker; easy to change (though still possible to ignore). Even if these recommendations were overlooked, there are still multiple levels of approval within publishing.

Discussion (15 min)

1. Identify Specific Accessibility Features

Discussion started with Chris’s prepared suggestions: (* indicates options recommended from others during meeting)

• Correct heading structure starting from h2
• Image description
• WCAG 2.0 recommendations for links
• Limit or warn high number links
• Correct tab index for links/headings
• Not allow use of bold/inline style for headings
• Provide accessible headings
• A11y checker in authoring interface
• Follows alternative content rules
• No downloads from links (need better way)
• No tab/window spawning (unless visual code given to user that it will happen)
• List features*
• Table features*
• Color contrast test* – could be handled by global CSS style?
• Media issues* (OneNet probably doesn’t address this)

2. Next Step

• Jon: Goal: build these into Management Content systems as a plug-in module to be able to add. Concern about making new editor completely (same problem as OneNet; branding issues mean it may not be commonly used)
• Mike implied: thought it would be possible just to update OneNet editor which was not tied to CMS. There could be advantages from creating a system with accessibility in mind from beginning compared to trying to graft into other systems
• Jon: Let’s find out what works best from a development standpoint; what is improvement over TinyMCE editor
• JaEun: Potential short term: custom configuration of TinyMCE, CP editor to save project time/resource?
• Suzanne: Notes that there are rules published in her content style guide (what not to do); potentially just make the editor prevent those mistakes entirely
• Lori: Color contrast (usually controlled outside editor)
• Jon: potential to bring Mike/other technical skills down to the University

Action Items

• Get Mike/technical people down here to assess possibility to see whether OneNet can be used within our Content Management System.
• Check Mike’s availability to schedule next meeting; let’s do this before attempting to address other tasks.

Date: April 14, 2016

Location: University Library, Room 323C

Attendees:
Ku, JaEun, Gunderson, Jon R, Weathers, William Fletcher, Lane, Lori, Hoyt, M Nicholas

Recap from the Previous Meeting

• Investigate text editor menu structure and its custom configuration to ensure a11y when the users author the contents (ie, heading structure menu should be more visible than styling menus such as bold or italic styling)
• Adding images and video to contents – “add media” UI in wordPress – how and in which way (tooltips, instruction underneath the alt text form field?) we can optimize UI for adding images (considering SEO, best image tagging practices and more) – ICEBOX

Preliminary Research

• WYSIWYG editor in OneNet: Jon Gunderson and Mike Scott – Texteditor from OneNet is built from scratch — back when we built it, Mike had trouble getting any of the existing editors (or the contentEditable implementation in browsers besides IE) to produce HTML that he could work with. He would be interested in working on updating and/or porting it over to TinyMCE if that’s something Library IT might be working on
• WordPress CKeditor
• CK editor 4 documentation: Nick Hoyt – CKEditor’s WCAG Checkpoints page, they are claiming that list markup and use of headings are not applicable. On top of that, the compliance page is based on WCAG 1.0. (WCAG 2.0 became a standard in December 2008)
• TinyMCE: WordPress default editor
• TinyMCE + Quail library in WordPress, which is also used at CKEditor accessibility checker: Jon Gunderson – the author will not be able to fix (or even understand) and the messaging from Quailjs.js rules will most likely not help the author to know how to fix the problem using TinyMCE or other WYSIWYG editors

Features for Accessibility

Text Editor

• Headings
• ALT text for images
• Lists
• Tables
• Continuous monitoring of accessibility

API Features to Support Accessible Authoring

• Configuration of editor to support custom feature
• APIs to support update editing controls based on context (e.g. heading level)
• APIs to inspect content before insertion (e.g. IMG ALT Text, Headers for Tables)
• APIs to support continuous accessibility feedback

Action Items

• Inspect APIs for accessibility features
• Setting up a test accessible editor