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.