Accessibility problems with the BUEditor

but had hoped that accessibility issues would be considered before rolling it out across d.o.

Itches get scratched...

What barriers are you talking about?

BTW. the process to implement BUEditor was 2 1/2 years old... I don't think that's "Fast"

Well good thing its not a WYSIWYG editor, or we would have issues

Here are my questions:

1. How would BUEditor make editing content for someone with accessibility issues worse than just a raw text fields?
2. What do you suggest to improve the experience for users with accessibility problems. Obviously, removing BUEditor is not going to happen.

There are no alt tags for the image

Which image? You mean image dialog?

I can't see how to navigate without a mouse to use it, the are accesskeys but they aren't consistently applied or added to the help documentation.

Admins can set accesskeys for buttons. There is even a small addition that turns accesskeys into Ctrl shortcuts.

@ufko

There are no alt tags for the image

Which image? You mean image dialog?

No, there are no alt tags for the input images.
http://www.w3.org/TR/html4/interact/forms.html#edef-INPUT

I can't see how to navigate without a mouse to use it, the are accesskeys but they aren't consistently applied or added to the help documentation.

Admins can set accesskeys for buttons. There is even a small addition that turns accesskeys into Ctrl shortcuts.

Ok, but only 8 of the 14 buttons have accesskeys so this is a valid complaint. Also, there isn't any documentation in the help like he said so I had to inspect the HTML to confirm this. I'm not an accessibility guru but that seems like a reasonable request.

@mgifford its unfortunate that accessibility didn't get reviewed. But you're review can easily fix it now so we don't have to rail on the process. We're all volunteers scratching our itch like greggles said.

@MGParisi This doesn't have to be personal. We all appreciate the effort. Lets just get this solved and have a better site.

What would be the next step? I'm not familiar with the code but if the accesskeys are admin configurable that sounds like a webmaster issue to decide the keys. Help text improvements and alt text on the images sounds like BUEditor module issues?

This is just another Drupal site using a module. Please file specific issue in that module's queue. When they release a new version, we can upgrade to it. Ideally, test things out on a fresh Drupal site so the issue reports are clear.

#1306760: Accessibility Issues - Add ARIA

@mgifford: Thanks for raising these concerns. Yes, d.o (sometimes) moves very fast and it can be hard to ensure everything gets all the right reviews. There's a point about "Accessibility" at Drupal.org development guidelines but it's not clearly defined. In the case of #1284694: Tweak UI of issue following (bluecheese) I knew it might be a problem, tagged that issue "needs accessibility review" and Everett replied in ~20 minutes with really helpful input. He remained engaged and reviewed/tested various iterations of the UI and in the end, I'm pretty happy with how it turned out. So, at the very least, we should get in the habit of tagging all d.o deployment issues that involve changes to the UI with the "needs accessibility review" tag and ensure *someone* gives it some thought before we push the changes live. @mgifford: if you have other specific suggestions on this, please add them to the page I linked.

@MGParisi: Please let go of the defensiveness. If people using screen readers or otherwise not using a mouse are having trouble with a new UI, let's be open to that possibility instead of writing them off (which is the sense I get from the tone of your replies). It's great when people take ownership of changes on drupal.org and drive them home (like you've done with BUEditor, I just did with issue following, etc), but we don't have to get personally attached to these features such that if people raise concerns we think it's directed at us as people. Yes, #424400: Use BUEditor on drupal.org was open for 2.5 years, but it was never tagged that it needed an accessibility review, and it's a little hard to expect that the people who need to care about that are going to follow every infra or webmaster discussion (not to mention other queues like drupalorg, project, project_issue, versioncontrol, versioncontrol_git, etc) hunting for possible changes that are going to make their life more difficult and deal with them before they're deployed. Usually, no matter how much you wave your arms and shout "change is coming, please review and test it now!" 99% of the community won't see it until it's live, and that's when they start caring. ;)

@skottler, @neclimdul: Thanks for your positive and productive contributions.

@drumm: Totally agreed.

@ufku: Thanks for the speedy turn-around on #1306760: Accessibility Issues - Add ARIA! However, we still need to deploy those fixes on d.o before we can call this issue closed. ;)

Are there any other improvements to fix upstream in the realm of improving accessibility of BUEditor? Is there going to be another official release in the near future, or should we just deploy from the end of the 6.x-2.x-dev branch?

Thanks,
-Derek

To be fair, though, people who can't access the new bar aren't any worse off than they were before because they can still use the text area as they always have. They were just left out of the new goodie. Not saying we shouldn't fix it but I can understand why MGParisi is feeling defensive at the accusatory tone that we are moving too fast and putting up barriers when that's not exactly the case.

Michelle

@DWW, @mgifford When I see #1306760: Accessibility Issues - Add ARIA I am happy.

I support accessibility, and see BUEditor as an accessibility enabler, not dis-abler. By its nature it is helpful to a large number of people who have disabilities, and though it may not have alt tags I hardly think we need to contact every group of people in the drupal world before moving forword. Each person would have issues related to the ticket, and lets be frank there are more blockers then doer's.

It also seemed that @mgifford did not read the entire proposal (all 100+ comments) as I did and his original comments and issue sounded rather entitled and arrogant. It didn't even seem that mgifford understood BUEditor or tried it as he was comparing it to WYSIWYG Editors. In addition, the current http://drupal.org/node/1127876 does not include "contact the accessibility team". If you want to include it I will suggest that you open a ticket to change the process.

With that said I am not defensive, Im more agressive. I want to get things done, not stop them in their tracks. I am glad that we got BUEditor up the way we did. As imperfect as it is, implementing it has injected new life into the project, ticket, and idea, and has started these discussions. Thus I don't think that the accessibility team should be contacted every issue, but they should be listened to, and if they have strong issues that need to be resolved and can be resolved; I will be the first to raise my hand in support. I also would love to take on a new project.

In this case improving BUEditor afterwords is easier then getting it installed.

Updated http://drupal.org/node/863568 to reflect best practice for accessibility.

Create ticket

Can someone create a ticket on how to improve the D.O. Deployment process on D.O. (aka http://drupal.org/node/1127876 ), I would love to see improvements in documentation including references to documents like http://drupal.org/node/863568

#1307688: Reorganize Drupal Process Documentation

What are the next steps forward to resolve this issue?

I did a super fast review of the editor before it was rolled out to d.o. I didn't check for everything, but primarily that the editor wasn't making things worse for accessibility.

I have not read through all of the above comments, in short the editor must:

1. Have buttons that can receive keyboard focus (in a logical order with the rest of the UI).
2. Show visually that a button has received focus.
3. Have meaningful alt for the images if the buttons are image buttons.

It would be nice if there were accesskeys / accelerator keys, for all buttons, but this is a follow-up issue.

Note: I successfully formatted the above list by selecting all lines and using alt+shift+o in Firefox 6 / JAWS 13.

BTW. the process to implement BUEditor was 2 1/2 years old... I don't think that's "Fast"

(Also building on comments from @dww/#12) - The issue did take a long time to result in something... but as with many parts of drupal.org and drupal itself, many people (myself included) had no idea this was happening / happened, other than seeing it when posting a comment on an issue one day.

Please don't take any issues people have with the implementation personally, as it simply came as a surprise to many (I'm sure @mgifford was included in that bunch), and surprises aren't always good :)

It would be nice, imo, if there were a change document somewhere that documented interesting improvements/changes to drupal.org itself, as this site is a major case study of Drupal's effectiveness, and the first thing I thought after seeing BUEditor is 'what is that? It might be nice for a few of my sites...' - but it took me a day or two to figure out what had happened / what was used (mostly because I was unable to get on IRC and simply ask someone).

Am I mistaken, but I see the shortcuts in the help...

Here is how browsers fire accesskeys: http://en.wikipedia.org/wiki/Access_key#Access_in_different_browsers.
It's even inconsistent between the versions of the same browser.

BUEditor displays shortcut hints for only IE(Alt) and Firefox(Shift+Alt which is apparently incorrect for Mac).

There is a small js library(bue.ctrl.js) included in BUEditor which standardizes shortcuts by registering Ctrl+Key shortcut for the textarea. It doesn't alter the accesskeys and Ctrl+Key shortcut hints are displayed in every browser.
The functionality can be tested on the dev site

Have buttons that can receive keyboard focus (in a logical order with the rest of the UI).
Show visually that a button has received focus.

This was disabled intentionally. See #492688: Use tabindex to get bueditor buttons out of the way.

Have meaningful alt for the images if the buttons are image buttons.

The dev branches of BUEditor defines alt attribute for all buttons including the text buttons.

I get the following

I read through #492688: Use tabindex to get bueditor buttons out of the way.. Removing UI controls from tab order breaks accessibility.

Can we make the buttons a 'toolbar' and provide at least one tab stop?

1. When 'Status' has focus one tab will take you to the editor toolbar.
2. When the toolbar has focus using the arrow keys take you to the buttons.
3. When the toolbar (any button) has focus one tab will take you to the Comment field.

If we implement this in JS the tabindex should also be altered in JS, so that the buttons are still accessible through tabbing when JS is disabled.

Can we make the buttons a 'toolbar' and provide at least one tab stop?

I've created a demo for this. The dev site(bueditor-drupal.redesign.devdrupal.org) seems to have file system problems.

If we implement this in JS the tabindex should also be altered in JS, so that the buttons are still accessible through tabbing when JS is disabled.

BUEditor does not install when JS is disabled.

Took a quick look at the demo. First impression is that it rocks.

• All buttons have alt text
• All buttons have accesskeys
• I can tab to, and then past, the toolbar in one tab each
• I can navigate the buttons w/ left / right arrows

I would suggest one improvement. The WAI-ARIA 'toolbar' role should be added to the button container, e.g.:

<div role="toolbar" aria-label="Comment editor"> ... toolbar buttons </div>

This will indicate to assistive technology the role and purpose of the list of buttons.

#1306760: Accessibility Issues - Add ARIA is in and BUEditor 6.x-2.5 has been released.
Attached is the editor used in the demo.

Attachment

+1 to the fixes in the module. See #1306760-17: Accessibility Issues - Add ARIA.

...coming from #1351642: Major UX issue: BUEditor clears the text area. Does this issue here aim to replace the already deployed version of the editor in d.o in order to fix the data loss issue on forward/backward navigation? I'm only asking because I can't tell from the issue's title and summary.

@klonos, This issue has no such aim, though it fixes that issue naturally by converting text buttons to images.

Bump. Was this ever fixed? If not, what do we need to do to get this deployed on drupal.org -- is it a patch for the BUEditor project, or something that goes into a config file on drupal.org?

Nope, not yet fixed, sorry. :( Looks like we need to:

- Deploy bueditor 6.x-2.6 to get the fixes from #1306760: Accessibility Issues - Add ARIA
- Update the bueditor editor configuration on d.o to use the new editor definition from #33. That just lives in the DB, AFAICT. There's no equivalent of default views that are managed in code that you can override, revert, etc.

It'd be great to get confirmation from ufku that that's all we need, and then to try both of the above on a test site before pushing this live.

Yes, that's all needed.
All accessibility issues mentioned here were fixed in the project.
The editor at #33 has some improvements over the current one:

1. Ctrl library is enabled to overcome inconsistency of accesskeys across browsers.
2. History library is enabled for cross-browser undo-redo in textareas.
3. Added images for code and PHP buttons.
4. Additional buttons: issue number, table.

OK... On my test site http://docs-infra-drupal.redesign.devdrupal.org I did the following:
a) Replaced existing sites/all/modules/bueditor directory with version 6.x-2.6.
b) Ran update.php (no updates were needed).
c) Went to admin/settings/bueditor. Clicked "Edit" on the "HTML Basic" editor.
d) Went to "Import buttons", and pasted the attachment from #33 into the PHP code box. Clicked "Import".
e) This seems to have left the old buttons and added new ones. So I selected all the old ones with the checkboxes and did "With selected... delete go" (and confirmed the delete).
f) Uh oh, that deleted the new imported buttons too. So I went back and imported the new ones again and this time (step d) and this time clicked "Save configuration".

So next time, I think I should delete the existing buttons first, then import the new ones.

Anyway, it isn't working correctly: the icons for the following buttons are missing/blank:
Quote
Code
PHP Code
Issue number
Insert Table

All of the buttons appear to be working though -- when you click them, you get the right stuff in the text box.

Accessibility:
- All of the buttons have alt text and titles (presumably a screen reader can read these).
- All of the buttons have keyboard access, and I tested that I could use all of them with just the keyboard.
- There is a tab stop on the first button, and next tab goes to the Comment field.
- If I stop on the first button tab stop, arrow keys can navigate through them.
- When my arrow keys are on one button, I can hit and it's as if that button was clicked.
- The toolbar has role="toolbar", but it doesn't have the aria-label attribute as suggested in comment #31.

Anyway, those icons are missing... Not sure how to fix that, and can we add the aria-label attribute too? Those look like the only problems.

If you would like to test this out, you can go to
http://docs-infra-drupal.redesign.devdrupal.org/user
The browser auth is drupal / drupal
Then log in as ariatest / ariatest
Visit http://docs-infra-drupal.redesign.devdrupal.org/node/1477932 (or any other issue page) and scroll down to the comments section to test the editor.

Digging a bit further...

On d.o, the editor configuration includes this:

  'iconpath' => 'sites/all/libraries/bueditor',

whereas the config in #33 is this:

  'iconpath' => '%FILES/bueditor-dorg/icons',

sites/all/libraries/bueditor has these files:

bueditor_buttons.csv
ico_a-blank.png
ico_a-center.png
ico_a-code.png
ico_a-justify.png
ico_a-left.png
ico_a-right.png
ico_bold.png
ico_break.png
ico_copyright.png
ico_h1.png
ico_h2.png
ico_h3.png
ico_h4.png
ico_help.png
ico_img.png
ico_indent.png
ico_italic.png
ico_link.png
ico_ol.png
ico_preview.png
ico_quote.png
ico_small.png
ico_strike.png
ico_sub.png
ico_sup.png
ico_teaser.png
ico_ul.png
ico_underline.png

However, the page source for this comment here includes markup like the following:

<input type=​"image" title=​"Heading 4" accesskey id=​"bue-0-button-5" class=​"bue-button bue-sprite-button editor-sprite-button" alt=​"ico_h4.png" src=​"/​sites/​all/​modules/​bueditor/​icons/​x1.png" style=​"background-position:​ -100px 0;​" tabindex=​"-1">​

/​sites/​all/​modules/​bueditor/​icons/​x1.png is a 1x1px image. Doesn't look like a sprite to me. ;) Although I do see a files/bueditor-sprites directory, so for example this is a more sprite-like sprite:

https://drupal.org/files/bueditor-sprites/sprite_e54934aedbe3623e54536fe...

So, I don't really understand WTF is going on here. ;) Looks like there's some JS magic happening in _bueditor_settle() to inject some sprite-related settings via drupal_add_js().

Anyway, it seems there is disagreement on the configuration, locations of icon files, etc. So that's probably why the icons are broken on the test site.

From #424400-167: Use BUEditor on drupal.org:

Deployed by Killes, Files where moved.

;)

For comparison, I'm attaching the export of the live editor on d.o in case that helps.

The button import UI imports only the button settings leaving the editor settings or icons intact.

You should have imported the whole editor using the editor import interface at admin/settings/bueditor/import. The "Directory of editor files" must be set in order to import the icons. But the dev server might not allow to write to files directory.

Attached the icons in case they need to be manually uploaded to the server.

I'm confused... Could you post step-by-step deployment instructions that I should follow, that tell me what I'm supposed to do with the text file in #33, and how to get that to replace the editor stuff that is there now without losing all the role/editor settings that are on d.o now?

1. Go to /admin/settings/bueditor/import
2. Enter Editor name. It can be an existing name.
3. Enter Directory of editor files. ex: bueditor.
4. Paste the contents of the text file from #33 into Editor code (PHP)
5. Select the existing editor used in the site in Overwrite field.
6. Submit the form

Make sure the Directory of editor files is only 1-level deep since it will be created by file_check_directory that does not support recursive directory creation.

If the dev server does not allow to write to files directory (which was the case when i was testing earlier), you should manually upload the icons and set Directory of editor icons under Editor paths settings after you import the editor.

OK, I'll try that, thanks!

Let me tell more about the import/export process to make it clearer.

An exported editor code, like the one in #33, contains all information about an editor, including icons and library files. Icons are exported using base64 encoding, so it's possible to include them in a text file. They are then decoded back to images and written to the editor directory specified in the import UI.

OK, here is what I did for this pass [Note thatthe previous pass had already done this: Replaced existing sites/all/modules/bueditor directory with version 6.x-2.6.]

1) On admin/settings/bueditor -- note that the editor that is there is called "HTML Basic"
2) Click "Import editor", taking me to admin/settings/bueditor/import
3) For editor name, enter "HTML Basic" (no quotes)
4) For directory, I looked to see what is currently in /files/bu*, and we have:
bueditor-1.png
bueditor.buttons.txt
bueditor-dorg/
bueditor.png
bueditor-sprites/
bueditor_with_texy_en.txt

The bueditor-dorg directory has an icons subdirectory in it, so I'll re-use that.
5) For PHP editor code, pasted the contents of the attachment in comment #33.
6) Select "HTML Basic" in the Overwrite field [Ah, I had missed that being present on the Import page before! It was not intuitive to me that if I imported I would be able to overwrite settings from an existing editor, which is why I went to Edit before.]
7) Save.

OK, this works to deploy the editor... All of the buttons are there, and I did the same accessibility tests as in comment #40, with the same results.

So the only remaining issue is this accessibility problem:
- The toolbar has role="toolbar", but it doesn't have the aria-label attribute as suggested in comment #31.

If anyone else would like to test, the instructions are in comment #41.

Let's discuss the aria-label in a BUEditor issue. If it's going to be added it should be a fixed text, otherwise we can't provide a semantic label for each textarea in the site.

OK. I am not an accessibility expert anyway... Someone other than me should probably give the demo an accessibility run-through, and if it's fine, we can ask the infra folks to deploy according to the instructions in #49. :)

I did a preliminary accessibility test on the BUEditor for comments. It's keyboard-friendly, which is very nice, but the dialog boxes for adding images, links, and tables are inaccessible.

Here's what I found:

• You can't tab to the cancel button to exit the dialog box.
• The form labels need to be <label> elements.
• There's nothing that tells you which fields are required.
• There's no error message when you don't fill-in a required field.

Thanks for the review!

This needs to go back to the BUEditor project, so I filed
#1505324: BUEditor still has accessibility issues (in dialogs)

Postponing this issue until the accessibility issues are fixed on that project.

I will also update the issue summary.

dcmoyard, Everett, or any other Accessibility expert:
ufku has posted on the other issue that updates have been made to the BUEditor dialogs to address these issues, and there is a demo site link in that comment. Can anyone go test it out please?

Summarize the issue

The BUEditor maintainer has (hopefully) fixed the problems, so the next step is to download that fix and make a test site (see issue summary).

Actually, there is already apparently a test site for the new version of BUEditor.
http://t1.ufku.com/contact

Can someone who knows about accessibility testing please test this, so that we can get a new version of BUEditor that everyone can use deployed? Thanks...

Also, I've requested that the maintainers make a new release with the (hopefully fixed) version:
#1593390: New 6.x release?

RE #58 - I am not sure I understand what you're saying, but the reviews need to go into an issue on the BUEditor project if there is a problem with the latest version on the demo site. Thanks! (and if you file a new issue there, it would be helpful to add a link here to the issue)

I don't think that we can ensure that the description of how to get help would be on every field where the BUEditor could be used, so I think we need to file this as an issue in the BUEditor project -- the toolbar itself needs to provide everything that would be required to make it accessible, right?

Thanks for the clarification... I've filed
#1597508: BUEditor accessibilty regression - no way to discover control keys
on the BUEditor project to ask them to put this information into the toolbar somewhere.

I'm not actually sure if we can easily add help text to the Comment Body and Node Body fields on drupal.org easily, and I'm not sure if there are other places BUEditor is being used...

Please can someone from the accessibility group respond to the latest comment on
#1337022: [policy, no patch] Create/adopt JavaScript docs standards compatible with a JS documentation parser? The maintainer says the button control keys are in the button image titles...

@jhodgdon: Copy-paste error? Did you mean #1597508: BUEditor accessibilty regression - no way to discover control keys?

Sorry yes -- dww is right, that is the issue I meant. Oops!

update status

Moving to the appropriate queue.