Project Updates

Accessibility Feature Identification

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.

OneNet Text Editor Demo

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.

Accessible Text Editor Options

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

Library Contents Review

Date: February 15, 2016

Location: University Library, Room 323C

Attendees:

Ku, JaEun, Gunderson, Jon R, Weathers, William Fletcher, Lane, Lori, Hoyt, M Nicholas, Chapman, Suzanne, Pionke, Jj

Interpreter: Bunita L Berg

Meeting Topics

            • A recap of library content example
            • Discuss:
              • Control for a11y inhouse plugin vs installed plugin
              • A Style guide, put through an accessibility check list
              • An Accessible text editor to ensure the a11y
              • What text editor component will be important
              • How we can improve editing or new text editor in WordPress
              • What components are unnecessary

Links

Discussion Items

Time Item Who Notes
15min Recap of library content example JaEun Library content review page
5min Style guide / a11y check for plugin JaEun Brief intro for project items
10min Accessible text editor demo JaEun Text editor example (1, default editor, CKEditor, accessibility CKEditor)
20min Accessible text editor discussion Jon ·  What text editor component will be important?

·  How we can improve existing or new text editor in WordPress?

·  What components are unnecessary?

10min Brainstorming for action items/project direction JaEun/Jon What is next?

Action Items

              1. Regarding text editor tool bar structure (put heading structure first and in-styling next; editing the configuration file in TinyMCE); assign this to William and JaEun
              2. Inserting image ui – ie. Consider what title is needed and used for, look at different ways of tagging images (for training or tagging example), SEO for alt image tag-tool tip, in red warning, just time in training, or block inserting the image (easily restrain image)
              3. Image, links (list), heading
              4. Jon will contact Mike Scott, DHS for State of Illinois for accessible editor – One Net – regarding heuristic approach for list items. Description for link rather than “click more”

Innovation Project Kick Off Meeting

Date: February 3, 2016

Location: University Library, Room 323C

Attendees:
Ku, JaEun, Gunderson, Jon R, Weathers, William Fletcher, Lane, Lori, Hoyt, M Nicholas, Slater, Robert, Chapman, Suzanne, Pionke, Jj

Interpreter: Bunita L Berg

Meeting Goals

  • Share the project goal and deliverable: URL for Innovation proposal
  • Come up with action plan to reach the project goals
  • Communication plan for the project

Meeting Topics

Introduction

  • Introduce team and collaborators: Name, Title, and Expertise in regards to web accessibility/disability resources
  • Icebreaker (10min): What is your grand plan for this weekend? What are you passionate about other than work?

Project Goals and Deliverables

  • Project goal/deliverable pertain to Library CMS
  • Project plan and communication plans (ex: Jira, IllinoisWiki (meeting note/decision making), code repository, email?)
  • Brainstorming for Collaborative efforts: How each member can support/contribute in reaching project goals with their expertise

Action Items

  • Ku, JaEun – IAAP ewebinar attendance – GSLS students and staff -1/28/2016 -done
  • Gunderson, Jon R and Ku, JaEun – student hire – job was posted two weeks ago and we received more than 12 applications. (Will hire a student after library content analysis)
  • Existing library content review – Suzanne will prepare library content examples (10 or so) for the group to review at next meeting
  • Investigate how likely developers can integrate a evaluation tool to monitor accessibility of content authoring practice. It could be stand alone tool, third party api or modification of TinyMCE text editor. (Will begin after library content analysis)