Improve accessibility of sharethis links

I took a look in the 7.x-2.1 tag of the module.

sharethis.module around line 354. This is the function that generates the markup. I don't think that it will be as simple as switching to links, because of the way that the Javascript behavior is attached, but I only took a quick peak.

But, the essentials are that:

1. The buttons need to receive focus.
2. They need visual focus indicators
3. They need to carry the semantics of buttons / links by:

a. using anchor or button elements.
b. using link or button roles. E.g. <span role="button" ...>

Going to take a look at this.

Modifying title since the admin UI needs work as well. Bumping to critical since using FF 6.x and JAWS 12 (screen-reader) there is no detectable presence of he links on the page.

Generated marup w/ default settings:

<span st_url=http://localhost/sharethis-7/node/1 st_title='Foo' class='st_twitter_large' displaytext="Tweet"></span>
<span st_url=http://localhost/sharethis-7/node/1
st_title='Foo' class='st_facebook_large' displaytext="Facebook"></span>
<span st_url=http://localhost/sharethis-7/node/1 st_title='Foo' class='st_sharethis_large'
displaytext="ShareThis"></span>

After doing some looking it appears that the JS for the links comes from an external source. Even adding role=link or changing the spans to anchors would not allow them to be keyboard accessible. It will be necessary to file a bug upstream, if possible.

I e-mailed ShareThis , their reply:

Right now we don't support accessibility compliance.
I have forwarded this suggestion to our product team.
I will update you on this once I hear from them.

I will update this issue if further information is provided.

Reply from feedback@sharethis.com to an e-mail I sent:

Right now we don't support accessibility compliance.
I have forwarded this suggestion to our product team.
I will update you on this once I hear from them.

The fixes might be able to be handled within the drupal module, depending on what is needed

The span tags get filled dynamically with widget code on page load.

If we added something like this:

<span role="button" tabindex="X" class="st_facebook_large"></span>

This would make those span tags that hold the buttons focus-able and role-wary. Would this work?

The only issue I see is that we wouldn't know what tabindex we were on since the buttons are added dynamically to the page. There also might be multiple sets of buttons on a page (like in a blog).

@jvalencia

role=button allows AT to know that the element is a button, and tabindex allows it to receive focus.

However, neither of these adds the .click handler, which from my * very * preliminary testing was missing i.e. you * have to click with a mouse * and cannot use the keyboard to activate the span. Would be happily corrected on this.

Again though, would you not be able to add a click handler in the Drupal module?

Something along the lines of attaching a key event that clicks the button?

Unfortunately, I'm not sure the widgets would be screen reader accessible either, but they might be ok.

Again though, would you not be able to add a click handler in the Drupal module?

* Yes.

Something along the lines of attaching a key event that clicks the button?

* Well, there is no button. But, the big problem, is what function to invoke when the 'button' is clicked. The function that needs to be invoked is stored in the external JS, and I assume is subject to change (?)

Off the top of my head, you can fire a "click" even from jQuery through javascript.

Then the "button" thinks it has been clicked regardless of what function it calls. The event handler takes care of what function to call.

Then the "button" thinks it has been clicked regardless of what function it calls. The event handler takes care of what function to call.

* I'd like to see this in actuon, or see documentation. I am not sure how the .click event can magically know which function to invoke.

I think that what you are saying is that you can tell an element to fire it's click event, and it will then invoke all registered click event handlers. This is true, but, I am not sure that there is a '.click()' handler attached to these spans, it might be mouse input only.

Regardless someone needs to either experiment, or dig through the mess of code in the external js to find out.

I just ran into this. And ya, too bad about the sharethis.com response. Adding a screenshot. Looks like we may need to use something else.

And their response from Twitter:
https://twitter.com/#!/ShareThis/status/184281373761216513

Hi there,

Right now, we still don't support accessibility compliance but we're planing to make ShareThis widget accessible in the near future. We will update you as soon as we make a production push. Thanks so much for your patience!!

Thanks,
Missy

And a year later? Any updates?

No accessibility = don't use the module.

We're removing this from every site we've added it on and replacing it with a better alternative that's designed for today's modern web.

Bad show, ShareThis

Curious what you went with.

Yes I'd also like to know. I'm not using this because of the (in)accessibility as well

Thought I'd have a look into this and wondered whilst we can't control the html sharethis produce we can change the wrapping span to a button - not sure this will work on ie7 though. This needs testing.

Also added some inline styling to take away the padding, background and border being a button would likely bring in.

This should allow keyboard only accessibility to at least share the content.

Forgot to mention this is using 7.x-2.8 branch.

Recreated the patch. hopefully this one passes.

Missed the styling. doh.

These look like useful changes to the code.

GaxZE mentions in #24 that the patch is for 2.8, so changing the version metadata for automated testing

Posting this patch in the correct format so it will pass testing.

One issue seems to be that it allows people to use the keyboard to select the buttons, but pressing enter does nothing.

Cheers. always seem to have issues creating patches in correct format.

@GaxZE: https://www.drupal.org/node/707484

Revised patch that turns an enter press into a click. This seems to work locally (though on Google+ and "Facebook Like" it requires an extra tab key press - which is just how their widgets work), it would be nice if someone else could test this as well!

Hello,

The patch works for configurations that contain the stMainServices class. (e.g. classic buttons). However, "Large chicklets" use the class stLarge instead. Changing the "button" variable code to:

var button = $.merge( $(this).find('.stMainServices'),
                      $(this).find('.stLarge') )[0];

works for both opthions. I am not sure that this is the best solution as there are other configurations that would have to be added to the list classes.

Thanks for the patch!

Made it more generic so that it will work for any class.

Previous patch broke mouse click in firefox as it could not deal with <button> elements.

This patch turns it into a <span role="button" tabindex="0">, and also now triggers also triggers on spacebar key press (as usual in screenreaders) instead of merely on enter key.

Hi stefan.r,

I can confirm that this patch is working for IE, FF, and Chrome!
Thanks!

Hi stefan.r,

I can confirm that this patch is working for IE, FF, and Chrome!
Thanks!

On my client side this has also been running on a couple of websites without any issues.

Does it make the buttons permanent, so that you don't need to fly over the small icon to make a panel of buttons appear ?

Thanks Stefan. #43 worked great. For anyone reading this, don't forget to add visual indication on :focus and :hover to make it compliant!

This still applies nicely. It's been RTBC for 3 months. An reason not to bundle it up into the repo?

Decent module and patch 43 worked great, it would be cool if it were included. :)

Thanks Stefan, works well.

Would be great to include in the module.

Thanks again Stefan.r, great work! I had to remove the inline style on the span element, so minor change, see interdiff_43_to_53.txt

RTBC +1

why are we removing it?

I had to remove the inline style on a site with lots of css because I think we had specified a background and when I installed the patch after upgrading to the latest version of sharethis the icons disappeared.

However the upgrade was necessary for us because it fixed a javascript exception that we observed only on apple iOS 9.0.2 ipads

For whatever reason upgrading to the latest sharethis and using your patch improved compatibility with apple iOS 9.0.2 ipads.

However when I first installed, the items were in the DOM as expected but some of the sharethis icons were invisible. it wasn't until I removed the inline styling as seen in comment#43 interdiff_43_to_53.txt that the sharethis icons became visible (after cache clear).

Thanks, this solved our issues with iPad 9.0.2. All other browsers we tested on work fine too.

I'm just wondering if we're not breaking anything by removing the inline styles, they may have been there for a reason...

Hi There,

Thanks for your patience here! We've made some changes in our support organization and we're working through responding to these. We know this is still an outstanding request, so we've escalated back up to our engineering team. We'll be sure to keep you posted on this!

Best
ShareThis Support

We did some accessibility audits on our sites and are close to dropping the use of Sharethis. I then came across this thread. What needs to be done to get this moving again? I can test the patch but it sounds like there needs to be some coordination with @ShareThis Support.

Patch in #53 still applies correctly but I agree with @stefan.r about removing the inline styles coming from Sharethis - they are probably there for a reason.

@ShareThis Support: it would be great to get an update on if there are any plans to change this on your end.

Re-uploading #43 and re-setting to RTBC

Previous patch was failed to load, so i have make some changes in this patch.

@Yogesh Pawar - any chance you can provide an interdiff to see what was changed. The patch before was RTBC so it should be pretty similar.

Hi @mgifford, Patch was failing to apply because of code changes in latest branch, he just re-rolled it accordingly with latest version.

Ok, thanks for the clarification @navneet0693

Do we need button.keypress(); as well as button.click();

EDIT: Also noticed this error
Notice: Undefined index: attributes in theme_sharethis() (line 322 of /home/drfxq/www/sites/default/modules/sharethis/sharethis.module). - See more at: https://drfxq.ply.st/node/1#sthash.FbXRjAPI.dpuf

@mgifford - this problem is solved in node - https://www.drupal.org/node/2547601. if we applied this patch then this error is removed.
yes we can use button.keypress() function also.

I have disabled the ci testing for 7.x-2.x branch b/c there are not any tests in the repo that's why ci was throwing error on every patch.

We have disabled the automated testing until we have tests

EDIT: Also noticed this error
Notice: Undefined index: attributes in theme_sharethis() (line 322 of /home/drfxq/www/sites/default/modules/sharethis/sharethis.module). - See more at: https://drfxq.ply.st/node/1#sthash.FbXRjAPI.dpuf

This doesn't seem to be caused by this patch, or is it?

-- removing comment, bad patch application on my part --

Any Update on this issue ?

Created a patch based on https://www.drupal.org/node/1289054#comment-10513614 but have added some other markup to display
the title attribute for the span tags and well as output the actual text of the sharing element for better screenreader descriptions.

Updating bad patch from previous comment.

I updated this patch to work with version 7.x-2.13 of the module. Note: this does not address the lack of keyboard focus on links and buttons in any externally loaded iframes, such as the email service modal.

Drupal 7 is no loner supported.
Marking as outdated.