437843 - musicload.de - Radio buttons not rendered on MusicLoad's payment method page.

Status: RESOLVED INCOMPLETE

(Tech Evangelism Graveyard :: German, defect)

Description

[Marco Zehe (:MarcoZ)]

Steps to reproduce:
1. Open www.musicload.de.
2. Under the "MusicLoad Charts" heading, choose one of the songs (for example "Kid Rock/All Summer Long", and add it to the shopping cart (Warenkorb).
3. Once it appears in the "Warenkorb" section, click the link that says "Hier gelangen Sie direkt zur Kasse".
4. On the following page, you're being asked for the payment method ("Wie möchten Sie bezahlen?".
5. Inspect the page using either a screen reader or DOM Inspector.

Expected: The radio buttons should appear as such in DOM inspector's Accessible Tree view, or should be discoverable using NVDA or JAWS.
Actual: The labels for the radio buttons appear, but the inputs themselves are not rendered as such. So, a blind person can view the text of each of the radio buttons, but has no way to activate them.

MusicLoad is Germany's most popular digital music store (even more popular than iTunes), and I've received inquiries about why this is not working correctly.

BTW it also doesn't work in IE, however that should not be a reason for us not to render the pages correctly.

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase

The problem is that the INPUT elements are styled with display:none.
There's a plain GIF image that looks like a radio button to the left
of the LABEL text and they use javascript to emulate behavior like
a radio control.

Comment 2

[Marco Zehe (:MarcoZ)]

(In reply to comment #1)
> The problem is that the INPUT elements are styled with display:none.
> There's a plain GIF image that looks like a radio button to the left
> of the LABEL text and they use javascript to emulate behavior like
> a radio control.

So this display:none on the div prevents the radio button from being visible, but because the text is associated with it via the label element, when clicking on the text, the radio button gets checked anyway. I don't see the image even using the JAWS cursor (screen exploration), but when I click on the text, the radio button gets checked (the next page after clicking the "Weiter" button behaves according to my selected payment method).

So we have two choices AFAICS:
1. Render the label not as the label, but as the radio button instead or
b) ignore the display:none that's inherited from the div and render the radio button anyway even though it is only linked to by the label.

The second approach has the danger of exposing something that can't be clicked.

The first option would not give the true picture, but at least allow the user to activate it like they are used to.

Any other ideas how to handle this?

Comment 3

[Marco Zehe (:MarcoZ)]

I've given this some more thought, and I believe we should expose these elements if they are explicitly linked to by a visible label element. We do something similar for hidden label elements that are explicitly linked to a visible input by giving the input the contents of the invisible label.

What do others think?

Comment 4

[alexander :surkov (:asurkov)]

Marco, even if we will provide accessible for the hidden input then I'm not sure screen readers will work correctly. They won't get box object (coordinates and size) and possibly they won't be able to prepare an action on that element (because iirc we send a click event).

In the case when label isn't visible but input we don't expose accessible object for label iirc, we just take the text from it to give a name for the label. So it's a bit different thing.

Comment 5

[Marco Zehe (:MarcoZ)]

(In reply to comment #4)
> Marco, even if we will provide accessible for the hidden input then I'm not
> sure screen readers will work correctly. They won't get box object (coordinates
> and size) and possibly they won't be able to prepare an action on that element
> (because iirc we send a click event).

OK, what about exposing a "click" action on that label instead? And everything else that tells screen readers this element is clickable? Because if  I use JAWS, route the JAWS cursor to the text of that label, and click on it, the correct payment method gets activated also, I don't need to click on the image.

Comment 6

[alexander :surkov (:asurkov)]

Attachment: patch (not tested)

Marco, how does it look?

Comment 7

[alexander :surkov (:asurkov)]

Attachment: patch2 (cvs)

Comment 8

[alexander :surkov (:asurkov)]

Attachment: patch3 (cvs)

Comment 9

[Marco Zehe (:MarcoZ)]

Comment on attachment 325381 [details] [diff] [review]
patch3 (cvs)

This patch causes an immediate crash when launching Minefield. First thing that pops up is the dialog asking whether Minefield should be set as the standard browser. Waiting a few seconds, crash occurs. Hitting "no" immediately when dialog appears, causes Firefox to immediately close down.

Comment 10

[alexander :surkov (:asurkov)]

(In reply to comment #9)
> (From update of attachment 325381 [details] [diff] [review])
> This patch causes an immediate crash when launching Minefield. First thing that
> pops up is the dialog asking whether Minefield should be set as the standard
> browser. Waiting a few seconds, crash occurs. Hitting "no" immediately when
> dialog appears, causes Firefox to immediately close down.
> 

Marco, I tried with Jaws - I haven't crash.

Comment 11

[Marco Zehe (:MarcoZ)]

Turn on the JAWS braille viewer in addition to JAWS itself. Do you get a crash now? What version of JAWS do you have?

Comment 12

[Marco Zehe (:MarcoZ)]

I crash at this hunk in nsAccessible.cpp:

>@@ -2863,7 +2867,7 @@
>       relatedNode =
>         do_QueryInterface(nsAccUtils::FindNeighbourPointingToNode(content, nsAccessibilityAtoms::aria_describedby));
> 
>-      if (!relatedNode && content->Tag() == nsAccessibilityAtoms::description &&
>+      if (!*aRelatedNode && content->Tag() == nsAccessibilityAtoms::description &&
>           content->IsNodeOfType(nsINode::eXUL)) {
>         // This affectively adds an optional control attribute to xul:description,
>         // which only affects accessibility, by allowing the description to be

Visual Studio debugger halts at the line:
>           content->IsNodeOfType(nsINode::eXUL)) {

Comment 13

[alexander :surkov (:asurkov)]

Marco, it sounds you applied patch2 but you should try the patch3.

Comment 14

[Marco Zehe (:MarcoZ)]

Comment on attachment 325381 [details] [diff] [review]
patch3 (cvs)

Resetting review flag for myself. Accidentally applied the wrong patch, they came in too fast for me :-)

Comment 15

[Marco Zehe (:MarcoZ)]

Comment on attachment 325381 [details] [diff] [review]
patch3 (cvs)

r+ for the test part, except the title which says "Accessibility table chrome tests" still. Please fix that nit upon checkin. :-)

I'll let Aaron review the code part. I do have a feeling this does not cover the original MusicLoad page yet: The text there does not get exposed as a label, but as a simple text leaf and a textframe containing it.

Comment 16

[Aaron Leventhal]

NS_IF_ADDREF(*aRelatedNode = relatedNode);

Just needs NS_ADDREF -- relatedNode is never null in that block of code.

Comment 17

[Aaron Leventhal]

Comment on attachment 325381 [details] [diff] [review]
patch3 (cvs)

Three reasons for minus:
1) Marco says it still doesn't fix the bug for JAWS users
2) No fix can address the keyboard navigation issues for all users. They need to fix their code.
3) We can't afford to add extra code for every terrible use of HTML and JS

This should be a tech evangelism bug. They really should use ARIA if they really need radio buttons with a custom look and feel. They can use activedescendant or tabindex for the key nav part.

Comment 18

[alexander :surkov (:asurkov)]

So, wontfix?

Comment 19

[Marco Zehe (:MarcoZ)]

(In reply to comment #18)
> So, wontfix?

I'm waiting for a reply from Asa from tech evangelism with a suggestion on how to approach the MusicLoad folks. This may get turned into a tech evangelism bug, so let's leave it open for now.

Comment 20

[Chris Lawson (gone)]

INCOMPLETE due to lack of activity since the end of 2009.

If someone is willing to investigate the issues raised in this bug to determine whether they still exist, *and* work with the site in question to fix any existing issues, please feel free to re-open and assign to yourself.

Sorry for the bugspam; filter on "NO MORE PRE-2010 TE BUGS" to remove.