When clicking "Next" in the inline editor, both the editable focus box (gray background) and the toolbar disappear, but the checking more still works well.

There should be no change in the editable focus stuff.

Overview

While working on #43 it turned out that we need to change the way QuickFixes are loaded.

Our goal was to load QuickFix class only on demand, since there might be 100+ QuickFixes in no time.

Current Implementation

Current implementation uses RequireJS loading class dynamicaly (based on runtime call, with user-defined string). That's impossible to build with RequireJS optimizer.

Current implementation can be viewed here:

• Engine.getFixType - which retuns the requested type.
• dynamical amd request, which takes care of loading.

Possible Solutions

If we want to keep modularity here, we need to create a convenient way to load QuickFixes.

We also might consider extensibility, so that developers can create their custom QuickFixes with ease.

QuickFix Repository

An idea for that is to make a singleton QuickFix repository object that would implement getting / loading logic. It would feature get method and would store loaded QuickFix types.

Since we can't use RequireJS at build, we would expose method to register type, eg. CKEDITOR.plugins.a11ychecker.QuickFix.register( name, class ).

Once register function is called it would call all pending callbacks for the given type. And next get calls for this type might be called back synchronously.

When user has fixed the issue (using a QuickFix or manually) the Accessibility Checker should attempt to find a next issue.

The order should be determined by the DOM order of the issued elements.

1. Open any sample with Accessibility Checker. (i.e. plugins/a11ychecker/dev/sample.html)
2. Enable Accessibility Checker.
3. Navigate to the second issue Use a long date format.
4. Use a Quick Fix to resolve the issue.

Expected result:
Next issue, titled Adjacent links that (...) should be focused.

Current result:
Accessibility Checker focuses the first issue, in this case is Paragraphs must not (...).

Prepare a nice graphics/styling for the Accessibility Checker in a listening mode.

It is also important to take care of its positioning in both classical and inline mode.

TC

1. Use the dev git branch.
2. Open any sample with Accessibility Checker. (i.e. plugins/a11ychecker/dev/sample.html)
3. Enable Accessibility Checker with button or hotkey.
4. Click in any non-issued area in editor editable.

Expected result:
A fancy information about Accessibility Checker listening for user actions.

Current result:
Nasty yellow information.

We should extract Quail checking engine to the separate plugin called a11ycheckerquail.

This idea came as a follow up of #5.

Guys what do you think, do we need an explict a11ychecker#validated event?

The thing is that main a11ychecker already has a a11ychecker#checked event which is fired when content is checked. It gets IssueList instance as a parameter. Having issue list you can easily check its size (issues count).

It seems to be logical that you can handle positive (as well as failed) validation in checked event.

Let me know what do you think about it.

It seems that we can't select the issue using mouse in certian situations.

1. Open any sample with Accessibility Checker. (i.e. plugins/a11ychecker/dev/sample.html)
2. Use "Source" toolbar button and set source to:

<p><strong>this is sample line</strong></p>

<p>Text with a short date of 12/04/2014, 2/1/14, 12-04-12, 12.04.12.</p>

<p>foo <a href="article.html">read more of</a><a href="article.html"> article</a> at its page</p>

1. Go back to wysiwyg mode.
2. Try to click at any of the issues.

Expected result:
Clicking the issues should show the balloon.

Current result:
Nothing happens.

Additional info:

1. Navgation over the issues works with keyboard hotkeys, so it's likely the problem is with a click listener.

Check for problems / fill the missing docs so it's generable with JSDuck.

This TC assumes that you have some Accessibility problems in the content.

1. Open any sample with Accessibility Checker. (i.e. plugins/a11ychecker/dev/sample.html)
2. Use the Accessibility Checker button to enable checking.
3. When the content is validated, and you see errors markup switch to source mode.
4. Switch back to the editor by clickling "Source" button once again.
5. Click Accessibility Checker button.

Expected result:
Content should be examined once again.

Current result:
Nothing happnes.

Additional info:

1. This is most likely due to Controller.enable not being restarted when detaching editable.

(balloon-ui 44d3e6d) piotrus@dragonus /...a11ychecker/bower_components/quail> grunt build
Running "bower:install" (bower) task
Fatal error: Arguments to path.join must be strings

I know that all of us hit it, so it must be finally fixed.

While preparing Accessibility Checker for #33 (building) we had to drop current approach for loading QuickFixes, which was based on RequireJS.

We need to create a solution for QuickFix types at runtime without calling RequireJS.

Soon I'll try to provide more informations on how we're going to achieve this.

Referring to #21, ViewerCounter tests should be merged with ViewerNavigation tests.

At some point I've removed inline demo. It's about time to restore it.

We should handle multiple issues within the same element.

Currently the problem is with orange marker in editable. After moving to second issue of the same element, border disappears, and focused element is not distinguishable.

To see multiple occurences with the same element you might use Quail imgAltNotPlaceHolder and imgHasAlt. To change that open EngineQuail.js nad find a line with:

    guideline : [ 'imgHasAlt', 'aMustNotHaveJavascriptHref', ... ],

Change it so it contains imgAltNotPlaceHolder:

    guideline : [ 'imgHasAlt', 'imgAltNotPlaceHolder', 'aMustNotHaveJavascriptHref', ... ],

It doesn't make any sense to hide them.

Some tests mainly integration tests fail in other browsers than Chromium.

We need to keep in mind that they need some love too.

Overview

We need to better job with styling ignored issues. At the moment I've used simply a dashed grey outline like on image below:

You might find it necessary to style non-ignored issues as well, to match new styling - feel free to do so.

How to style issue markup?

All the elements causing the issue are marked with cke_a11ychecker_issue class.

They also will gain cke_a11ychecker_ignored if they're ignored. To be precise: if all issues caused by given element are ignored.

Issue might be also focused (when GUI balloon is shown), in this case it will gain cke_a11y_focused class.

Non-ignored issues feature one of following classes: cke_a11ychecker_error, cke_a11ychecker_warning, cke_a11ychecker_notice. This class will indicate its severity. //Note: this class is not currently removed when issues are ignored.//

The CSS styling these elemnts is located in <plugin>/styles/contents.css file.

How to see ignored issues

Assuming that the content in sample has some invalid markup.

1. Open any sample with Accessibility Checker. (i.e. plugins/a11ychecker/dev/sample.html)
2. Enable Accessibility Checker.
3. Use Ignore button ( at this point you will see ignored and focused issue).
4. Use next button to move to the next issue ( at this point you'll see ignored issue without focus).

Expected result:
Appropriate, nice highlighting.

Please remember:

• To differentiate focused issues from the others.
• In case of non-ignored issues end-user must be able do differentiate different servenity of non-ignored issues just by look of it.

Current result:
Ugly temp highlighting.

Additional info:

1. We'll have also to do something about the ignore button itself, but this will be a case for another issue.

1. Enable a11ychecker.
2. Press ESC or click "x" - balloon is closed, but error borders are not removed.

It seems that we've missed one important point when storing testability. It can't be stored in data-cke-testability attribute, because multiple issues can refer to the same element.

Therefore each issue would override previous value.

Quail seems to hang when we'll use all of its tests to check our sample.

We need to investigate what's the reason for that.

Update:

It seems that Quail simply checks whole page, and it takes long time, rather than hanging. See comments for more details.

Call to Controller.close on uninited a11ychecker throws an exception.

It would be much more developer-friendly if implementation will check if Accessibility Checker is closeable itself.

1. Open any sample with Accessibility Checker. (i.e. plugins/a11ychecker/dev/sample.html)
2. Exec following code using the JavaScript console:

CKEDITOR.instances.editor1._.a11ychecker.close()

(note: Accessibility Checker must not be inited with exec method before)

Expected result:
Nothing should happen.

Current result:
An exception is thrown: {{{Uncaught TypeError: Cannot read property 'clear' of null}}}

Additional info:

1. It's a blocker for #11

1. Press CTRL+ALT+E.
2. Checker is enabled, but balloon is not displayed.
3. This means that you can now edit document which should not be editable.

1. Open any inline sample with Accessibility Checker. (i.e. plugins/a11ychecker/dev/sample.html)
2. Open a balloon for any issue.
3. Click on dropdown.

Expected result:
Dropdown should unfold and wait for user action.

Current result:
Balloon hides.

Additional info:

1. It's a regression, was working in 2acad34

We have invalid focus when we'll focus the issue using the mouse.

1. Open any sample with Accessibility Checker. (i.e. plugins/a11ychecker/dev/sample.html)
2. Click on the image marked as issued.

Expected result:
A balloon appears.

Focused item depends QuickFix availability:

• If QuickFix is available:
  • If it's fully automatic - the "Quick fix" button should be focused
  • If it's semi-automatic (require some fields to be set by a human) - the first input element should be focused
• If no QuickFix are available - the next button should be focused

Current result:
No element is focused.

We should add an extra class to editable when we're doing results highlighting.

That will allow us to highlight all elements with data-a11y-ignore attribute only in checking mode with CSS. At the same time it will prevent them to be highlighted when Accessibility Checker is off (because data-a11y-ignore is present in normal content too).

That should be implemented in Controller CheckingMode init / close methods.

Ensure all hotkeys are available while balloon is focused. So far I see that there is problem with Accessibility Check toggle hotkey (CTRL+ALT+E).

We should check what version of CKEditor is required in order to run Accessibility Checker. This information should be included into README.

Overview

Actually I came with that idea while working on #27.

We might leave subtle highlight for issue elements in listening mode. That will allow end users to have a better orientation on errors, keeping him focus on his job, rather than toggling between states all the time.

I created following screens that demonstrate the idea:

Checking mode:

Listening mode:

We need to perform a JSCS check against all the code in Accessibility Checker according to our rules in CKEditor repository.

In inline editor, any non-handled keypress is propagated up to the editable.

1. Open any sample with Accessibility Checker and inline CKE. (i.e. plugins/a11ychecker/dev/sample.html)
2. Focus any a11y issue.
3. Press any key, eg. F, left arrow etc.

Expected result:
Nothing should happen.

Current result:
Keystroke is propagated to the editable.

Basically as mentioned in issue title.

Overview

After revisiting the fix introduced in #38 we got an impression that it might be actually a good idea not to hide Accessibility Checker upon editor blur (both inline and classic).

Sample problems with current solution

The extra problem was change introduced witch #41. It forces to focus the editor on... editor blur (in case of enabled Accessibility Checker). It makes impossible to leave a editor in a first click, which is very annoying.

Proposal

Lets try how it actually works when Accessibility Checker is not closed with editor blur.

TC1: Direct code execution

1. Open any sample with Accessibility Checker. (i.e. plugins/a11ychecker/dev/sample.html)
2. Open JavaScript console, and execute following line:

CKEDITOR.instances.editor1.execCommand( 'a11ychecker.next' );

TC2: Hotkeys

1. Open any sample with Accessibility Checker. (i.e. plugins/a11ychecker/dev/sample.html)
2. Focus the editor.
3. Press CTRL + E

Expected result:
Nothing should happen.

Current result:
An exception is being thrown: Uncaught TypeError: Cannot read property 'count' of null

There should be a way to filter out issues returned by the engine before they will make it into Controller.issues.

This functionallity should be implemented in Engine class and allow inheriting classes to override it.

We need to somehow include information about total count of issues found.

This information is crucial for UX.

Initially we were thinking about replacing issues dropdown with a information like <cur issue> / <issues count>.

We should remove all the a11ychecker markup from editable when user blurs the inline editor.

1. Open any sample with Accessibility Checker in inline editor. (i.e. plugins/a11ychecker/dev/sample.html)
2. Enable Accessibility Checker.
3. When balloon will appear, simply click outside of the editable - so editor is blurred.

Expected result:
All the extra markup produced by Accessibility Checker (with an exception of data-a11y-ignore attr) should be removed.

Current result:
All the classes added by checker are still there, so eg. issues are still highlighted.

Additional info:

1. But, we need to be careful here I can see that, eg. after applying a QuickFix in inline editor, whole toolbar flickers. That tells me that blur occurs there.

We're convinced to the multiple controller modes approach, so we can merge it into the master.

Along with that we should drop old branches like classesRefact, demoModes. And current controllerModes branch should be renamed to dev.

Remember about README.md updates.

We should create a type for buttons (possibly other parts of the UI too?).

The reason behind it is that we'll have unified handling for stuff like space / enter in one place, rather than reimplementing it all over again.

We should also create a deriving class PushButton which would be used as ignore button in #20.

Overview

We can't forget to keep the plugin UI accessible.

This will especially come down to handling QuickFix form and issues navigation.

Issues Navigation

Using a screen reader user should be able to determine:

• What kind of an issue is focused.
• What element caused the issue?
  • I think we should inform about element type: header, paragraph, list item.
  • We should read issued element inner text.
• How many issues remains.
• Are there any QuickFixes available.

QuickFix Form

We need to put extra attention to error reporting.

In case of invalid value in any field, user should be notified about the error. Possibly we should also move focus to the first problematic field.

We should unify behavior of Accessibility Checker when no a11y issues are detected.

Cases

Checking empty document

1. Open any sample with Accessibility Checker. (i.e. plugins/a11ychecker/dev/sample.html)
2. Clear the CKEditor contents, using "New Page" button.
3. Execute Accessibility Checker, eg. by clicking a its toolbar button.

Fixing the last problematic element

1. Open any sample with Accessibility Checker. (i.e. plugins/a11ychecker/dev/sample.html)
2. Set the CKEditor contents using "Source" button to:

<p>This is a sample date: 12-04-12.</p>

1. Execute Accessibility Checker.
2. Navigate to the issue, eg CTRL + E.
3. Apply a Quick Fix.

Expected result:
For the time being alert with an appropriate message will be sufficient.

We need to avoid using padding for issue highlighting as it may lead to some layout problems later on.

As for now padding is used for .cke_editable .cke_a11ychecker_issue selector, in contents.css file.

Currently we're inserting scratchpad to the CKEDITOR.document.

Since Accessibility Checking engines rely on calculated styles for elements inside the inspected element, we have to make sure that styles will be applied to the content in scratchpad too.

This is especially important in case of a classic editor (since it's wrapped in an iframe).

The second thing is that scratchpad is currently maintained by the Controller class. It should be moved to EditableDecorator.

This is a regression, most likely introduced in a05804a (#38).

After performing a quick fix, the Accessibility Icon in toolbar is disabled. Therefore I assume Controller.enabled is changed.

1. Open any sample with Accessibility Checker. (i.e. plugins/a11ychecker/dev/sample.html)
2. Navigate to the first issue which supports quick fixes.
3. Apply quick fix.

Expected result:
Checker should remain in checking mode. Toolbar icon should indicate that Accessibility Checker is on.

Current result:
The icon goes off, as if Accessibilty Checker would be disabled.

Additional info:

1. I guess it might be a good idea to see if it's possible not to close balloon each time we change focused issue, but only update its contents.

The a11ychecker must correctly handle undo manager - most of the time it must be blocked, but quick fixes and fixes done in edit mode should be recorded.

#16 changed UI for ListeningMode. Tests must be refactorized to consider that change.

We need to make sure that all the content used in Accessibility Checker is localized.

We should include issue testability information.

For the time being it should be sufficient to place it somewhere in the balloon. Eventually we might to indicate lower testabilities with a different highlight color.

Toolbar button no longer indicates that a11yc is running.

We need to provide a way to ignore accessibility issues

We need to think if we really need a bulding process.

As for the core of Accessibility Checker we might need it because of RequireJS usage. So it will output concatenated and minified plugin source.

As for building Accessibility Checker Engines, like Quail - well, most likely they'll end up in separate plugins. In this case building an engine would be simply an installation step.