Re: [orca-list] problems with audible.com and latest orca

[Joanmarie Diggs <jdiggs igalia com>]

Hey John.

Sighted users look at the appearance. And both Cancel and Preview look
like buttons.

In general, this situation describes both the awesomeness and the
(potential) awfulness of web apps. Web developers can style elements up
so that they look like widgets, and they can make those elements act
like widgets via javascript. And, like that old saying about ducks, if
it looks like a widget and it acts like a widget, then it's a widget,
right? That's all very cool. But without the use of ARIA to tell user
agents and assistive technologies that they are widgets and not
paragraphs and divs and the like, we're in big trouble.

--joanie

On 05/30/2015 05:43 PM, covici ccs covici com wrote:
> Thanks so much -- but then I wonder, how does a normal sighted user do
> anything with this at all?   I wonder if you click that now text, does
> preview change to something you can click on?  Very strange to me -- I
> really appreciate all you have done for Orca, it has improved so much
> over the past few months.
>
> Joanmarie Diggs <jdiggs igalia com> wrote:
>
> > Hi John.
> >
> > I've got good news and bad news.
> >
> > On 05/30/2015 05:07 AM, covici ccs covici com wrote:
> > > Hi.  I am having problems navigating audible.com with orca -- I am using
> > > the mode where each link is a separate line and when you go into
> > > audible, each word is a link, at least at the top of the page.
> >
> > This one I can reproduce. And while it is a consequence of how Firefox
> > renders offscreen/not visible text when authors set the width, I may be
> > able to hack around it safely and will try to do so.
> >
> > Regarding this next one:
> >
> > > next problem requires credentials -- once you sign in and search for a
> > > book, the give as a gift window is not working properly -- it seems to
> > > work, till you get to the preview item which you can tab to, but is not
> > > a link, clickable or anything, is this something you can fix?
> >
> > I can reproduce it. However, I cannot fix it. Looking at my debug.out,
> > when I tab to the Cancel push button I see this:
> >
> > ----------> QUEUEING FOCUS: [PUSH BUTTON | CANCEL] (0,0,0)
> > ----------> QUEUEING OBJECT:STATE-CHANGED:FOCUSED [PUSH BUTTON | CANCEL]
> > (1,0,0)
> >
> > In other words, two events saying an object of role push button whose
> > name is "Cancel" got focus. Compare that to what I see when I tab to
> > Preview:
> >
> > ----------> QUEUEING FOCUS: [PARAGRAPH | PREVIEW] (0,0,0)
> > ----------> QUEUEING OBJECT:STATE-CHANGED:FOCUSED [PARAGRAPH | PREVIEW]
> > (1,0,0)
> >
> > Preview claims to be a paragraph. Orca has no way of knowing it's
> > something else.
> >
> > When I look at the associated markup, I see:
> >
> > <input value="Cancel" title="Cancel" type="submit">
> >
> > So that's how Gecko, and thus Orca, know Cancel is a button. In
> > contrast, for Preview I see:
> >
> > <p tabindex="0" class="btnOrange preview" id="adbl-gift-previewbutton"
> > title="Preview"><span>Preview</span></p>
> >
> > Audible can fix this via ARIA markup, setting the role of that paragraph
> > to "button". If they do so, Gecko will know it's a button and will pass
> > that information along to Orca. Since you are a paying Audible customer,
> > I encourage you to pass this information along to them so that they can
> > fix it.
> >
> > --joanie