Dashboard block reordering not accessible to screen-reader (keyboard?) users

This uses jQuery UI's sortable API, and currently doesn't have a fallback. I heard some work was done on accessible alternatives to drag & drop in Drupal 7, are there good examples or guidelines to follow?

This issue really belongs where the problem is, that is how we are managing every other issue.

It will take awhile, but we are closing out issues in Drupal.org Redesign, in favor of the the Webmasters, Infrastructure, and other issue queues linked at http://drupal.org/taxonomy/term/13. Tags are the best way to track these issues, http://drupal.org/project/issues/search?text=&projects=&assigned=&submit....

Bumping version since 6.x-2.x is no longer being developed.

Fair enough. I am not sure of a good approach to handling this, though. How have jQuery draggable elements been made accessible in other sites / projects?

Any movement on this?
Is accessibility still an issue?

It still is an issue with the D6 version, though I haven't tested to see if it's fixed with D7.

With the home page on Drupal.org there are a couple accessibility issues that WAVE tossed up. I think the search boxes without labels will be fixed with the upgrade to D7.

However, the biggest issue with homebox I think is in not being able to access the controls to add, configure or delete the blocks without a mouse.

Since many sites will want to set up a dashboard for their users to access content that is relevant to them, this is a pretty big issue.

EDIT: Yes, this is still an issue with the D7 version.

Changing versions as this is still an issue with the 7.x code.

I haven't actually tested this, but it seems like this could work.

Add role="link" to the span that has the settings/navigation.

Insert some text so that AT knows what the link does. Then make that span invisible to the browser so that nobody else can see it.

Hi Mike,

I didn't test the patch, just looked at the code.

<span class="portlet-icon portlet-settings" role="link" class="element-invisible">

All new lines have double classes on each element.

In addition, I’d question the span elements anyway. Semantically you click on those spans and something happens. For me that is clearly a button element.

As an interactive element the button is already in the tab order, and can be operated by screen reader users. No additional role or tabindex attributes necessary.

@BarisW - there's nothing wrong with more than one class span class="portlet-icon portlet-settings" that's also wasn't changed in the patch. Do let me know if I'm misunderstanding though.

@yatil - good point about the button and then not needing to worry about tabindex is good to know.

I'm attaching a patch with buttons, but it definitely needs js & css love.

I meant the double class attributes, not the double classes. See the highlighted piece of code in #12

Right.. I looked at that and then looked at it again and didn't see it. I think somehow class="element-invisible" got glued into my head as it's own entity. Thanks! Not sure how I missed that after you pointed that out.

Oh yes, a related issue from core #1719640: Use 'button' element instead of empty links

Well, this is a bit closer, but I the hover/focus still isn't working properly, so it's hard to know when you're over the right button.

I just did some brief testing on /testbox and it is mostly working. Having this done right is going to be more important for mobile too. The action areas are just pretty small for anyone.

Ok I haven't changed this, but really don't think the portlet-header isn't using good semantics here. The header is a bunch of action links rather a description of the list of links that's coming next. it should much more be something like:

  <div class="homebox-portlet-inner">
    <h3 class="portlet-header">Block controls</h3>
      <ol>
        <li><button class="portlet-icon portlet-close"><span class="element-invisible">Close</span></button></li>
        <li><button class="portlet-icon portlet-maximize" class="element-invisible"><span class="element-invisible">Maximize</span></button></li>
        <li><button class="portlet-icon portlet-minus" class="element-invisible"><span class="element-invisible">Minimize</span></button></li>
        <li><button class="portlet-icon portlet-settings"><span class="element-invisible">Settings</span></button></li>
      </ol>
      <span class="portlet-title">Recent content</span>

    <div class="portlet-config">
          <div class="clearfix"><div class="homebox-colors">
          <h4 class="homebox-color-message">Select a color:</h4>
          <ol>
            <li><button class="homebox-color-selector" style="background-color: #e4f0f8;"><span class="element-invisible">Color: #e4f0f8</span></button></li>
            <li><button class="homebox-color-selector" style="background-color: #c4d5b4;"><span class="element-invisible">Color: #c4d5b4</span></button></li>
            <li><button class="homebox-color-selector" style="background-color: #ecc189;"><span class="element-invisible">Color: #ecc189</span></button></li>
            <li><button class="homebox-color-selector" style="background-color: #ec8989;"><span class="element-invisible">Color: #ec8989</span></button></li>
            <li><button class="homebox-color-selector" style="background-color: #6b6b70;"><span class="element-invisible">Color: #6b6b70</span></button></li>
            <li><button class="homebox-color-selector" style="background-color: #4b97e5;"><span class="element-invisible">Color: #4b97e5</span></button></li>
            </ol>
         </div></div>
         </div>
     <div class="portlet-content content">No content available.</div>
  </div>
</div>

Changing status. Although there are still problems with the existing patch. It's much more accessible than what's there right now.

That patch really doesn't work against the git repo. Seems everything has changed since I wrote this patch.

I simplified it by not switching the links to buttons. They are no longer empty links though so this should help deal with keyboard accessibility. I've also added better i18n support.

Also against the git repo, but using buttons this time. The links with invisible text inside it didn't seem to work.

trying to address the styling added by the button change.

I've added the background back to the buttons so that the images show up. I've also changed the order so that the tab order is logically.

This works, but the order of the buttons doesn't fit with the template.. No idea why. The JS must be reversing the output for some reason.

It also isn't working on SimplyTest.me any more. However, other than the ordering issue, it works now with the latest version of the code.

Buttons are in the wrong order, so I have to set this back to Needs work.

As this stopped in 2014 I'd like to ask, if someone could perhaps create a separate issue and review the Drupal 8 / 9 version (2.x)?

This may be picked up now with 3.x as it contains several fixes. With 2.0.x-alpha1 the module is kind of "usable" for the first time. Please help and contribute to make homebox "great again again......." ;D

Doesn't seem to be major, if it wasn't solved for 13Y ...

Fixed in 3.0.x with the all new implementation. Using the element-invisible logic from above.