Closed
Bug 437843
Opened 17 years ago
Closed 14 years ago
musicload.de - Radio buttons not rendered on MusicLoad's payment method page.
Categories
(Tech Evangelism Graveyard :: German, defect)
Tech Evangelism Graveyard
German
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: MarcoZ, Unassigned)
References
()
Details
(Keywords: access)
Attachments
(2 files, 2 obsolete files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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•17 years ago
|
||
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.
Reporter | ||
Comment 2•17 years ago
|
||
(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?
Reporter | ||
Comment 3•17 years ago
|
||
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•17 years ago
|
||
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.
Reporter | ||
Comment 5•17 years ago
|
||
(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•17 years ago
|
||
Marco, how does it look?
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Comment 7•17 years ago
|
||
Attachment #325376 -
Attachment is obsolete: true
Attachment #325380 -
Flags: review?(marco.zehe)
Updated•17 years ago
|
Attachment #325380 -
Flags: review?(aaronleventhal)
Comment 8•17 years ago
|
||
Attachment #325380 -
Attachment is obsolete: true
Attachment #325381 -
Flags: review?(marco.zehe)
Attachment #325380 -
Flags: review?(marco.zehe)
Attachment #325380 -
Flags: review?(aaronleventhal)
Updated•17 years ago
|
Attachment #325381 -
Flags: review?(aaronleventhal)
Reporter | ||
Comment 9•17 years ago
|
||
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.
Attachment #325381 -
Flags: review?(marco.zehe) → review-
Comment 10•17 years ago
|
||
(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.
Reporter | ||
Comment 11•17 years ago
|
||
Turn on the JAWS braille viewer in addition to JAWS itself. Do you get a crash now? What version of JAWS do you have?
Reporter | ||
Comment 12•17 years ago
|
||
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•17 years ago
|
||
Marco, it sounds you applied patch2 but you should try the patch3.
Reporter | ||
Comment 14•17 years ago
|
||
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 :-)
Attachment #325381 -
Flags: review- → review?(marco.zehe)
Reporter | ||
Comment 15•17 years ago
|
||
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.
Attachment #325381 -
Flags: review?(marco.zehe) → review+
Comment 16•17 years ago
|
||
NS_IF_ADDREF(*aRelatedNode = relatedNode);
Just needs NS_ADDREF -- relatedNode is never null in that block of code.
Comment 17•17 years ago
|
||
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.
Attachment #325381 -
Flags: review?(aaronleventhal) → review-
Comment 18•17 years ago
|
||
So, wontfix?
Reporter | ||
Comment 19•17 years ago
|
||
(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.
Updated•17 years ago
|
Assignee: surkov.alexander → german
Status: ASSIGNED → NEW
Component: Disability Access APIs → German
Flags: review-
Flags: review+
Product: Core → Tech Evangelism
QA Contact: accessibility-apis → german
Version: Trunk → unspecified
Updated•17 years ago
|
Summary: Radio buttons not rendered on MusicLoad's payment method page. → musicload.de - Radio buttons not rendered on MusicLoad's payment method page.
Comment 20•14 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Updated•10 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•