Re: [uf-discuss] Request for help from screen reader users from the BBC
On 28/5/08 13:41, Alasdair King [EMAIL PROTECTED] wrote: Hi Alasdair Big thanks for this - really interesting and helpful. One or 2 comments inline Hi Michael, I'm sorry, I didn't mean to imply any mendacity on your part. I'm fully appreciative and admiring of the BBC's long-term support for accessibility, including BETSIE, informal support for my BBC-using programs, and use of accessibility features like skiplinks. That said, I recognise the difficult legal, political and regulatory environment you're in: otherwise I'd be writing Don't use microformats: publish a podcast of your programmes with DRM-free video and audio content with audio descriptions at the other end instead and that wouldn't be helpful to you, right? Smile. Yeah, fair cop. It's what we'd like too but as you say due to the unique way the bbc is funded etc etc etc ;-) Apologies for getting snarky - we've been trying to get an answer to this for the last 6 months now I'm arguing the following: 1 You have a large potential base of non-technical, vision-impaired users. They really are not technical. They often don't understand the Windows Start menu, how Windows Explorer works, the difference between an executable and a shortcut on the desktop, the difference between HTML as opposed to text format email. They have a set of heuristic techniques and processes they have been shown by volunteers or nephews and follow them to perform the task they want to do. Some have JAWS, lots more have NVDA or Thunder, few know how to change their preferences or what that means. They turn on the computer and press the keys they have learned to press to do what they want, and that's it. If what they get out isn't what they expect, they'll try the keys again or restart the computer. It's incredibly time-consuming, but it's independent activity. Yup, point taken. Still it would be nice to have real data to point to about how users use screenreaders. Hopefully, we'll be doing this research soon 2 There was a recent discussion on the British Computer Association of the Blind mailing list about how hard blind users found the iPlayer pages: well-constructed, fully-accessible web pages, with accessible Flash embedded. Good, accessible design from the BBC as always, but still people having problems. Why? Because it's really difficult to use a screenreader, relative to a sighted person. The cost profile is higher and different, in formal usability terms. The solution (I believe) is to provide tools (programs) that let vision-impaired users do the things they want to do easily. For example, I have a well-regarded (free) Accessible BBC Listen Again program that scrapes your BBC Listen Again pages and presents the contents as an alphabetically-ordered list. Menus control the station. Hit Return to Play, Escape to Stop. Volume resets when you close the program in case the user accidentally turns it off and can't get any subsequent sound. The point is not to provide every feature of your Listen Again pages, like the links to the station websites, but to make it really really easy to do the core function: listen to the radio with just a few buttons. It's tricky. Sometimes making a site accessible for one community makes it less useable for another. In general we try not to ghettoise users into areas of (dis)ability but this sounds like something the bbc should support on bbc.co.uk?!? Anyway it sounds cool. I'll mail you off list for the details. I'd like to do this with your television stations, and with your old archived output when it's available. If you end up with a bunch of web pages I'll write a scraper/crawler, but if you use microformats it'll make it much easier and more reliable for me to produce a putative Accessible BBC Archive program. And if microformats spread from you to other sites, then more data will become machine readable and more simple tools or scripts for vision-impaired users will be possible. Hence my support. Bbc.co.uk/programmes is designed to be machine accessible. For now this just means schedules available as json and unflavoured xml: http://www.bbc.co.uk/radio4/programmes/schedules/fm.xml http://www.bbc.co.uk/bbcfour/programmes/schedules.json But over time we'll add json, xml, yaml, rdf, ical, xspf, rss2, atom across the app. So hopefully you'll never have to scrape screens again. It does raise the question of whether it's worth supporting microformats. At the moment the main driver for keeping them is the move towards indexing ufs and rdf-a by yahoo etc. I'll keep people informed if those talks progress A move toward rdf-a is still on the table 3 Working in web accessibility leads one to mix with highly-technical professional screenreader users. They should not, I argue, be your target audience. A highly-technical JAWS user will write a script to get round ABBR problems and distribute it to other users, or just use the webpages for sighted people, or turn
[uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds]
Two example pages: html titlePage 1/title link rel=next rev=prev href=page-2 body div class=hentry h1 class=entry-titleEntry 1/h1 p class=entry-contentContent./p /div /body /html html titlePage 2/title link rel=prev rev=next href=page-1 body div class=hentry h1 class=entry-titleEntry 2/h1 p class=entry-contentContent./p /div /body /html As I understand the semantics of next/prev, they indicate links to separate resources - not a continuation of the current resource. i.e. These pages represent two separate feeds, each of which contains a single entry. The reason some XFN parsers will recurse to rel=me next and rel=me prev links is not the next/prev relations, but rel=me -- they can spider rel=me links (presumably constrained to a particular depth limit) and consolidate the information into a single unified profile. -Toby ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds]
Oh, I see. Thanks for clearing that up Toby. Still, do you see any way of tieing two hFeeds on separate pages together? Any way at all? I'm thiking in terms of data portability... If the service X doesn't provide an EXPORT your data but marks up content with hAtom, some parser could export all the archive by following that feed through multiple pages. -- André On Thu, May 29, 2008 at 1:01 PM, Toby Inkster [EMAIL PROTECTED] wrote: Two example pages: html titlePage 1/title link rel=next rev=prev href=page-2 body div class=hentry h1 class=entry-titleEntry 1/h1 p class=entry-contentContent./p /div /body /html html titlePage 2/title link rel=prev rev=next href=page-1 body div class=hentry h1 class=entry-titleEntry 2/h1 p class=entry-contentContent./p /div /body /html As I understand the semantics of next/prev, they indicate links to separate resources - not a continuation of the current resource. i.e. These pages represent two separate feeds, each of which contains a single entry. The reason some XFN parsers will recurse to rel=me next and rel=me prev links is not the next/prev relations, but rel=me -- they can spider rel=me links (presumably constrained to a particular depth limit) and consolidate the information into a single unified profile. -Toby ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds]
André Luís wrote: Still, do you see any way of tieing two hFeeds on separate pages together? Any way at all? The best way that I can come up with involves a slight extension to hAtom. The current hAtom spec only covers a subset of the full Atom spec. In particular, to cover feed consolidation, you'd want to implement in hAtom an equivalent to the id element in Atom. Because class=id or rel=id look a bit confusing (confusion with the id attribute) I'd suggest: rel=feed-id rel=entry-id rel=entry-id isn't really needed for this task, but if you're in a situation where the same entry could appear on several pages, then it may be useful. The feed id assigns a unique ID (in the form of a URI) to a feed. If two hAtom feeds have the same ID, it should be safe to assume that they're different HTML representations of the same underlying logical feed. Going back to my original examples, this could become: html titlePage 1/title link rel=next rev=prev href=page-2 link rel=feed-id href=urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 body div class=hentry h1 class=entry-titleEntry 1/h1 p class=entry-contentContent./p /div /body /html html titlePage 2/title link rel=prev rev=next href=page-1 link rel=feed-id href=urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 body div class=hentry h1 class=entry-titleEntry 2/h1 p class=entry-contentContent./p /div /body /html OK, that solves part of the problem - a way of determining if two hAtom pages represent the same underlying feed. However, given that these pages may be on opposite sides of the Internet, to consolidate the feed we need a way of finding them. For this, I'd suggest using rel=meta, an existing rel value which is used to link to additional metadata. Because rel=meta is often used to link to RDF files, it may be helpful to RDF parsers to explicitly include the type attribute. Adding all this to the mix gives us: html titlePage 1/title link href=page-1 rel=feed-id link href=page-2 rel=next meta type=text/html body div class=hentry h1 class=entry-titleEntry 1/h1 p class=entry-contentContent./p /div /body /html html titlePage 2/title link href=page-1 rel=feed-id prev meta type=text/html body div class=hentry h1 class=entry-titleEntry 2/h1 p class=entry-contentContent./p /div /body /html What do other people think? -- Toby A Inkster mailto:[EMAIL PROTECTED] http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
