STR: 1. Go to any page that has links. 2. Right-click any link and select "Share this link". 3. If you haven't set up any social API providers yet, a panel will appear that has the text "Select providers to add". Below it is an iframe that has a set of graphic icons that lead to different providers for sharing. These do not have alternative text. As a consequence, the contents of the src attribute is used to read the graphic to the screen reader. In case of data URLs, this is the base-64 encoding of the graphic. Each provider needs an alt attribute added that clearly states the service name like "Twitter", "Facebook", etc. Also, these are not tabable. They are pure images without an associated link. So, tabindex="0" should be added so they can be tabbed to with the keyboard, and Enter and Space should activate each item, too, not just a mouse click.
Points: --- → 3
OS: Windows 7 → All
Hardware: x86_64 → All
I've updated the development server with fixes for this. You can test by changing the preference social.shareDirectory to https://activations.paas.allizom.org/sharePanel.html
I can confirm that the graphics now all have labels. However, tabbing jumps to container elements that are parents of the graphic. So the screen reader always says "section", but nothing else. I have to use an exploratory command to find out which is the child graphic. If this is a constraint, please add role="button" to these container elements. That *should*, in theory, get the child graphic's name/alt text and add it to the button label. But please give me another try at this, this might be a bit trickier. It would be easier if these were real button elements instead.
I've added role=button since that is the simple fix, if that doesn't work I'll rework the template to use button elements. https://activations.paas.allizom.org/en-US/sharePanel.html
OK, the name is now doubled. So it says "LinkedIn LinkedIn", which could probably be due to a bug in the code that calculates the name from either attributes or the sub tree. We should definitely investigate if a rework to make these divs true buttons isn't really the cleaner approach. The role and tabindex attributes could be omitted, and there would be only one handler that would do the magic, not two. The @type attribute can be used to denote this as a button, not a submit, and thus make it work and valid even outside a form element. Tabbing, proper keyboard accessibility and keyboard focus outline would all come for free.
Ok, I changed it to buttons, which did simplify stuff. I am however uncertain if I should move the images alt attribute to the button, or leave where it is. I've updated the dev server.
I believe alt is an invalid attribute on the button element, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button, so leaving it on the img is fine. We still somehow double the name, but I've filed follow-up bug 1110676 to correct that in the a11y API.
Depends on: 1110676
Having said that, I think this is OK to be moved to the production location (after review of course). :)
Is this a server bug? Assuming so I don't think we should track this in the Firefox backlog.
Flags: firefox-backlog+ → firefox-backlog?
It is a server bug and a push request has been done in bug 1118819
Depends on: 1118819
fixed per comment #9
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.