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.