Open Bug 683613 Opened 13 years ago Updated 2 years ago

expose RSS feeds presence via accessibility API

Categories

(Core :: Disability Access APIs, enhancement)

enhancement

Tracking

()

People

(Reporter: surkov, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access)

We were requested to expose the presence of RSS feeds to AT. It appears object attribute "rss:true" on tab document accessible is suitable solution. Objections, thoughts?

Can we cc somebody from UI team to get a help with available API in Gecko to get this information?
What are all the ways this is currently shown visually?
(In reply to David Bolter [:davidb] from comment #1)
> What are all the ways this is currently shown visually?

this information is available in Bookmarks menu and menu of Bookbarks toolbarbutton (subscribe to this page).
Severity: normal → minor
Severity: minor → enhancement
Right, we removed most of the feed UI in bug 578967. The state of the bookmark menu item is the only indication that visual users get, and that's already exposed to accessibility, right?
(In reply to Gavin Sharp from comment #3)
> Right, we removed most of the feed UI in bug 578967. The state of the
> bookmark menu item is the only indication that visual users get, and that's
> already exposed to accessibility, right?

Yes, but the idea behind this is to announce important information about loaded web page to blind users. RSS is considered like something that might be interesting for the user. Some screen readers do that but current approach based on UI inspection what is bad practice (since it browser dependent and UI may be changed from version to version). So we need to provide an unified way for screen readers to get this information.
Why are RSS notifications more important to blind users than visual users?
(In reply to Gavin Sharp from comment #5)
> Why are RSS notifications more important to blind users than visual users?

This question doesn't have really answer. There are always debates whether should blind users have special ways to get information or shouldn't. The following example might be hypertrophied example but it can describe things well. When user reload the page then we send reload event by accessibility API and screen readers announce it. So why we do that because UI allows to detect that the page is reloaded.

This feature was requested by AT vendor and I'm inclined to think they know what they ask for. If they think this feature will improve users experience for blinds then I'm ready to buy it. On the another hand either we provide them in-low way to get this information or they will be forced to detect that from our UI. The second option makes screen readers to act as Firefox extensions what is not good way to proceed I think.
The reload example isn't quite the same - there is a visual indication that the page is reloading for visual users, and so it makes sense that there also be an accessibility notification. There is no visual indication of the presence of RSS feeds for visual users, so it would make sense to me that there not be one for accessibility.

I don't think "because AT vendors asked for it" is sufficient reason for us to add APIs. We decided in bug 578967 that it isn't desirable to provide an indication of the presence of RSS feeds to our users (blind or otherwise). Deciding on the important of RSS notifications seems like a UI/UX issue that's outside of the purview of AT vendors.
To be clear, comment 5 wasn't meant to be a loaded question. If there are good arguments for why this needs to be exposed differently for AT, we can expose it. But "because someone asked" is not a good argument.
(In reply to Gavin Sharp from comment #7)
> The reload example isn't quite the same - there is a visual indication that
> the page is reloading for visual users, and so it makes sense that there
> also be an accessibility notification. There is no visual indication of the
> presence of RSS feeds for visual users, so it would make sense to me that
> there not be one for accessibility.

RSS feeds presence is exposed to users as 'Subscribe to this page' of Bookmarks menu. AT could inspect UI to detect RSS. The same thing is for reloading page example. AT could inspect/watch UI to expose this to blind users. That was hyperbolic example but don't see a point why I couldn't use it.

> I don't think "because AT vendors asked for it" is sufficient reason for us
> to add APIs.

Ok, I'll ask them elaborate on this and see if they are ok to share their reasons. But, for instance, having JAWS announcing RSS presence for IE but not for Firefox might be considered as lack of blind users support by Firefox. And if this feature is sensible for blind users then why would AT vendors asked for it is not good enough reason. Shrugs.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.