Wow, it takes *so long* to read a page that way! Even google.com takes forever; their nav bar at the top has a bunch of “hidden” items, which the reader picks up.
So, it seems like there should be a way of chunking the page, making it easy for the screen reader to jump to a certain section. This is perhaps possible with link anchors, but there should be a better way, following the structure of the page. Once you’ve been through the whole page serially, you probably don’t want to do that again.
Haha, yeah, linear navigation is quite a change from what we’re used to. Luckily, most screen readers have a whole bunch of keyboard commands built in that help you move around. For instance, with WebAnywhere, try Ctrl-H to skip paste the whole top part of the page to the first actual heading.
I would like if there were a way to skip paste chunks within the navigation though. That’s where I think maybe tucking the items in a ul might help but I need to play with it first.
Apparently the standard screen readers (which cost money and are better than this web one) have a way of saying that the page has been updated, but I don’t think any of them can identify which part of the page has been updated in order to read just that part. (Though that really doesn’t seem that hard… just compare the DOM tree? Hmm…) I read about a hack that lets you set the focus to an element that has tabindex set to -1 but I want to understand it better before I suggest using it.
Thanks for the link, that’s probably a better part of the site to link developers to than the part of that site I found earlier today. I’ll add it to the wiki page.