Just noting some serious accessibility problems I noticed & posted here - #1306752: Accessibility problems with the BUEditor

Probably they should belong here with the project, but they were added to d.o & so a more immediate concern for users on Drupal.

For a comparison with CKEditor's accessibility, see:
http://ckeditor.com/blog/CKEditor_and_WAI-ARIA_means_Usable_Accessibility

Comments

ufku’s picture

Status: Active » Postponed (maintainer needs more info)

Could you please post a more specific issue report about this?

MGParisi’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)

As mentioned, and marked, Duplicate... Or should we duplicate out the infra discussion and keep this one?

ufku’s picture

Title: Noting Accessibility Issue » Accessibility Issues
Version: 7.x-1.2 » 7.x-1.x-dev
Status: Closed (duplicate) » Fixed

Ok, the first and only one i can see is the missing alt attributes for input tags.
I've just committed the fix for 7.x-1.x and 6.x-2.x branches.

Please reopen if there are other issues.

mgifford’s picture

Thanks. I'll have to look at this in more detail. I'll have to take a look at the code.

mgifford’s picture

Title: Accessibility Issues » Accessibility Issues - Add ARIA
Status: Fixed » Active
Issue tags: +aria

Add WAI-ARIA role="application" to tell the assistive tech to pass keys through to the browser / page and not to handle them on its own.

Some links on this:
http://www.w3.org/TR/wai-aria/roles#application
http://www.accessibleculture.org/articles/2011/02/not-all-aria-widgets-d...

Everett Zufelt’s picture

@mgifford

Can you explain why we should add the application role? I don't think that it is the best idea in this scenario.

The purpose of the application role is to tell assitive tech, like screen-readers, to interact with browser UI directly, and to pass keys though to the browser, instead of trapping them.

If the editor buttons indeed have accelerator keys (not accesskey attribute) but w/ JS, then it is likely best to:

1. Wrap the entire editor (buttons and text area) in role="application" and to make sure that the accelerator keys are discoverable.

If, however, only accesskey attributes are being usd for accelerator keys then I would recommend against role="application" as most assistive tech / browser combos support this natively, w/o application role. The accelerator keys still need to be discoverable (documented) somewhere.

mgifford’s picture

I'll default to you here. Maybe we just need to make sure that it's clearly discoverable.

ufku’s picture

Here is an example BUEditor with one image button (Bold)

<div class="bue-ui">
  <input type="image" accesskey="B" title="Bold (Shift + Alt + B)" src="ico_bold.png" alt="ico_bold.png" tabindex="-1" class="bue-button">
</div>

It uses the accesskey attribute for buttons. The input element has a custom click event.
There is no JS key binding. (There is an add-on library that binds Ctrl+Accesskey to the textarea keydown event, but that's not the case in d.o and it does not alter the accesskeys.)

How about setting the alt attribute as e.g. "Bold (Accesskey: B)" to make it discovarable?

mgifford’s picture

I'm waiting to hear back form Everett on the accelerator keys.

Do you have a demo we could look at with the add-on library that binds Ctrl+Accesskey to the textarea keydown event?

ufku’s picture

Here on the dev site
http login: drupal/drupal
drupal login: bananas/bananas

You can test it on the book form

mgifford’s picture

That's much better.

There still needs to be some way to alert users about how to get to the '?' icon. Once you get there it tells you which control characters to use which is great.

ufku’s picture

Status: Active » Fixed

I've committed the changes Everett suggested under #1306752: Accessibility problems with the BUEditor

The changes can be observed on the demo.

Let me know if we can improve it further.

mgifford’s picture

Amazing! Now it's just a matter of having a stable release that will roll out to d.o & then hopefully g.d.o..

Thanks again!

Everett Zufelt’s picture

Status: Fixed » Needs work

I would say that the toolbar of buttons should still be wrapped in:

<div role="toolbar"> ... buttons ... </div>

Thanks

ufku’s picture

Status: Needs work » Needs review
  • Added role="toolbar" to the UI
  • Moved tabindex from toolbar to the first button, which I think is more practical as it starts the left-right navigation immediately.
  • Updated the demo
Everett Zufelt’s picture

Nice. Using JAWS 12 / FF7

When I am reading by line I hear 'Toolbar with 16 buttons', when tabbing through controls I hear 'Toolbar' spoken when I reach the buttons.

ufku’s picture

Status: Needs review » Fixed

Committed. New releases are ready.
Thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jhodgdon’s picture

Note: for anyone still following this issue, there is a follow-up on BUEditor accessibility:
#1505324: BUEditor still has accessibility issues (in dialogs)

mgifford’s picture

Just as a note role="toolbar" is no longer in the toolbar in the demo. Is this still current?

mgifford’s picture

Issue summary: View changes

adding link for clarification.