Project Updates

Usability Testing Planing

Meeting Agenda

  1. New features review – a11yfirst checker, show block
  2. Known bugs – double scroll, anchor
  3. Next feature items – link, image
  4. Second round of usability testing goals –  See U of I box folder (Login required)
  5. Recruiting testers for usability testing (Jemma and Dena)
  6. A11yfirst Editor deployment process to Library CMS – meeting with Library IT/Training materials(ie. “getting started” video)/ collaboration with DRES accessibility Badging training system
  7. Go live target date to WordPress dev and stage sites – Nov 30, 2017
  8. Versioning strategy – current one is 0.5.0/ how to inform users that the editor was updated.
  9. Demo site maintenance and update –  “save” and “edit” functionality
  10. Review A11yfirst help file – https://github.com/a11yfirst/plugins-dev/tree/a11yfirst/plugins/a11yfirsthelp/content

Block Format Change & Milestone Release

Topic:

Conceptual Model for block format

  • Menubox with check box for block format is getting complicated.
  • Two main categories of conceptual model re “block”
    • simple block such as p, pre
    • complex block such as template, block quote
  • Implied conceptual model in ckeditor is that their block format menu is “simple block”, so it does not allow nesting.  In fact, block format is complex block
  • Bottom line is why don’t we simply use block quote menu button and use block format menu – advantage is using CKeditor way.

Block Format Implementation

block format menu – no gutter design next to menu items – used rich combo box instead of menu list

Next Milestone Release

Next milestone release will be on the week of September 25 and the project website demonstration page will be updated accordingly. This milestone will included complete heading plugin, link plugin, instyle plugin, blockformat and accessibility checker.

Attendee:

Nick Hoyt, JaEun Jemma Ku

A11yFirst Library Installation Meeting

Topic:

  1. Deployment Schedule
    • we would need more time to deploy the editor to the library – changes some design for format plugin
  2. Library deployment issues – “source view” configuration
  3. “Getting started” material – notice on users when they are about to use A11yFirst editor
  4. Git repository restructuring for deployment
    • WordPress Plug-in – JaEun Jemma Ku needs to start working on the plugin.
    • Code dissemination
      • A plugins directory with only the plug-ins directory
      • A sample directory with sample implementations and installation and configuration options
  5. “Getting Started” Objectives
    • Communicate organization values accessibility
    • What is accessibility
    • Information access for people with any level of abilities, including people with disabilities
    • Support assistive technologies
    • Support operating system built-in accessibility features
    • Communicate that editor will help you achieve organizational goals for accessibility
    • Communicate that editor is different than other editors and what the differences are
    • Set the context
      • First time user of the editor should read this material
      • Unobtrusive for other sessions

For more info, please see “Getting Started” page

Participants:

Jon Gunderson, Robert Slater and JaEun Jemma Ku

Accessibility Checker

Using the CKEditor Accessibility Checker

  • Provide a way to monitor or get the number of errors
  • Prevent publishing based while there are errors

Heading Plugin

  • Create a TOC based on headings
    • Creates a dialog box with links to headings or allow editing of heading text and levels
    • Insert a TOC into document
  • Highlight headings on that page (outline)

Getting started material

  • Help section for each plugin goest to central A11yFirst Help plugin.
  • Each A11yFirst plugin help contents are also part of global “Getting Started Material” material.

a11yfirst help plugin data flow and potential UI design

“Getting Started” Material

Ideas

  • Getting started plug-in (dialog)
  • Getting started video
  • Web page with standard and a11yFirst editors
    • This would allow comparison of two editor features

Getting Started Topics

Purpose is to help orient people to accessible authoring and to the features of the A11yFirst plug-ins.

  • What is accessibility and why is it important
  • Heading structure
  • “Format” versus “Inline Style” menus
  • Why link text matters
  • How to create ALT text and long descriptions

Why the editor is different (constrained):

  • Improved compatibility with assistive technology (A11y)
  • Branding consistency through restrictions in format and inline style
  • Improved use of document structure for SEO compatibility
  • Improved document flow and organization for readability

Usability Testing Result Discussion

Participants:

Dena Strong, Jon Gunderson, Nick Hoyt and JaEun Jemma Ku

Topic:

  1. Usability Testing Report (Login Required)
    • Confusions by users
    • Standard mismatch
    • Functionality issue
    • Users’ preferences
  2. Orienting materials for text editor users : “Getting Started” -> Need to orient users regarding A11yFirst editor
    • Heading level
    • Format vs style
    • Text editor vs visual editor
    • Basic accessibility awareness – why link text matters
    • How to create ALT text

* Based on discussion today, all the design specification documentation was updated.

Ongoing Evolution

Meeting Agenda

Discussion Topics:

We talked about

  1. Specific design change for heading plugin, link plugin, in style plugin (all the change details were recorded in Design Resource documentation.
  2. Schedule for staged deployment and packaging for WordPress CMS
  3. Ongoing Evolution(Aka. future plans)
  4. Final innovation project report

Participants:

Jon Gunderson, Nick Hoyt, JaEun Jemma Ku, Robert Slater

Action Items for Library CMS Deployment

Participants:

Robert Slater, Jon Gunderson, and JaEun Jemma Ku

Agenda:

    1. Findings from usability testing
    2. Design scope for block format
    3. Action items for deployment: what should be done to deploy a11yfirst editor to library WordPress CMS?

3. 1 Must Have Features

      • Reduce special characters (Jemma will create a list)
      • Add paragraph justify
        • Left
        • Right
        • Center
      • Format Features
        • Blockquote
        • Pre-formatted (pre)
      • Image ALT text checking
        • Check document on insert for ALT text
        • This is a plug-in that only allows editing of ALT text
      • Accessibility Checker
      • special character options -reduce the number of chars

3.2 Nice To Have Features

    • List style options
      • No-bullet
      • Extra line spacing
      • Highlight (colors and border)
    • Paragraph
      • Hightlight (colors border options)

* Note: a11yfirst editor has two “find and replace” and we should keep only one.

 

Comparative analysis of treatment of “paragraph” / “norrmal” behavior

Summary:

In the July 21 meeting, we decided to compare different editor interfaces’ behavior around  what happens when things with different levels of block formatting and inline formatting are tagged with Normal / Paragraph styles.

I compared Word Online, Word desktop, Google Docs, Gmail, Adobe Dreamweaver, the Confluence Wiki (used by wiki.illinois.edu), Drupal 7’s CKEditor implementation, Publish.illinois.edu’s TinyMCE implementation, and Box Note.

The analysis of the findings are below, followed by a table of data.

Strong standards:

  • Every editor surveyed files “normal” (or “body” or “paragraph”) with the headings.
  • Every editor surveyed changes “headline” to its “normal” style when that is selected.
  • Every editor surveyed doesn’t remove a link that’s in place when “normal” is applied over something with a link in it.
What this result suggests:
  • These are behavior standards that people have reason to expect everywhere they see editor interfaces. That provides a strong established-behavior-based reason to follow these standards.
  • These behavior standards don’t cause accessibility problems that we’re trying to actively change people’s behavior with.  So we don’t have correspondingly strong behavior-altering reasons to break these standards.
  • We’re not trying to specifically block people from being able to create paragraphs the way we’re trying to specifically block people from being able to use the phrase “read more” in a link. “Read more” is getting active programming countermeasures to combat people’s link-making behavior. But we don’t have an accessibility problem caused by people using paragraphs to try to prevent.
  • Providing interfaces that follow established expectations does provide an accessibility benefit for people with cognitive disabilities, in addition to a usability benefit for everyone.

Moderate standards:

  • The majority of editors don’t remove “bold” formatting when “normal” is applied over something that is bold. 
  • Word and Google Docs both do remove “bold” formatting.
There are two ways to look at this result:
  • CKEditor’s default behavior mirrors the numeric majority of editors, so staying with its default behavior will reinforce the numeric majority’s definition of standard behavior.

(or)

  • Word and Google Docs have a large amount of user mind share between them, and people likely spend more time in Word and Google Docs than the other editors (giving them a higher “time percentage” than “number percentage” of behavior-setting exposure time).  

No standards:

  • Different editors disagree in 4 different ways on how to handle it when a “bulleted” item is then assigned to “normal.”
  • With no clear standard set, we wouldn’t be breaking any  clear expectations with whatever decision we make. 
There are two ways to look at this result:
  • We can choose to leave CKeditor’s default behavior as the default here.

(or)

  • If we’re looking to establish A11yFirst as something that’s clearly different than unmodified CKEditor, following Word’s behavior rather than unmodified CKEditor would be a way to emphasize the difference.

The raw data

What it’s called
Headline 
Bulleted list
Inline bold / link
Word Online
“Normal”
(found in same group as headings)
Becomes “normal” style
Becomes “normal” style
Bold is removed and becomes “normal”. Link is not removed.
Word Desktop (Windows)
“Normal”
(found in same group as headings)
Becomes “normal” style
Becomes “normal” style
Bold is removed and becomes “normal”. Link is not removed.
Google Docs
“Normal text”
(found in same menu as headings)
Becomes “normal” style
Font and size become “normal” but list is still bulleted
Bold is removed and becomes “normal.” Link is not removed.
Gmail
“Normal” (found in same menu as headings)
Becomes “normal” style 
No change
No change
Adobe Dreamweaver
“Paragraph” (found in same menu as headings)
Becomes “normal” style
Paragraph tag is nested within LI tag
No change
Confluence Wiki
“Paragraph” (found in same menu as headings)
Becomes “normal” style
No change
No change
Drupal 7 CKEditor 
“Normal” (found in same menu as headings)
Becomes “normal” style
Paragraph tag is nested within LI tag
No change
Publish. illinois WordPress WYSIWYG
(TinyMCE Editor)
“Paragraph” (found in same menu as headings)
Becomes “normal” style
No change
No change
Box Note
“Body” (found in same menu as headings)
Becomes “normal” style
No change
No change