Accessible Sites: Follow Standards or Follow Browser Bugs?
Following on from a post by Kev in another thread:
| Kev wrote: |
| As I understand it, thats a limitation of the screenreading software. In these days of (some) people making a concerted push to favour standards over software shouldn't we be saying that in this case its down to screenreader manufacturers to get their software up to speed? Its an idea I got from Joe Clark in his book and one I personally agree with- no one uses <blink> or <marqee> anymore so why should we make allowances for other limiting software |
It's a very good point, we're kind of back to the standards vs proprietary browser tags argument but just in a different way.
We need to be pushing screen readers to get their act together to comply with the startards, not creating standards that say 'deal with this bug'!
Although I can see why this is done, a user with special needs doesn't care about why something doesn't work, they just want it to work.
Accessify Forum Administrator ~ Nigel Peck / MIS Web Design
"Everything I say is not meant to be set in stone" - Van Morrison
Share: 
This issue comes under Guideline 10 (Use interim solutions) of WCAG 1.0. Considering those guidelines are over 4 years old now, it's disgraceful that content developers should still have to consider any of those issues, with the possible exception of popup windows. 4 years is a long time in technology years.
Do all screen readers have problems with adjacent links, or is it restricted to a few?
Does The Web Standards Project have any clout in getting these companies to address the issues?
Share:
| gez wrote: |
| Considering those guidelines are over 4 years old now, it's disgraceful that content developers should still have to consider any of those issues, with the possible exception of popup windows. 4 years is a long time in technology years. |
I think it's even more than 4 years
Looking foward to the day when we follow WCAG 2.0 guidelines!
Build Your Own Web Site the Right Way!
A beginners' HTML/CSS book with web standards at its heart
The Ultimate HTML Reference
A complete reference, in glorious hardback
Share:
| gez wrote: |
| Does The Web Standards Project have any clout in getting these companies to address the issues? |
Does anyone know anyone with WaSP? It seems to me they've had pretty good luck getting the major browser makers in line ... I think it's time they turned their sites on the screen readers.
Share:
| Nigel Peck wrote: |
|
Although I can see why this is done, a user with special needs doesn't care about why something doesn't work, they just want it to work. |
I agree completely here. Outdated browsers are one thing. I think people who still want to use presentational HTML to send Netscape 4.x a pixel-perfect facsimile of what they're sending IE5/6 users are wasting their time. If someone using an old browser gets a slightly different look, or even an unstyled page, what's so bad about that? They still get the content, and they have the option to download up-to-date software, anyway.
But a blind user, for example, might not get the content, if we don't accomodate his software. And even if a new version of a screenreader fixes a problem, it won't be free to download. There's a small user-base and there's been no screen-reader war to kill the price-tag.
But I would accept that it depends on the site. I think Joe Clark rightly says that not every page need be accessible to everyone. If it's a photographer's site, say, it's visual by it's nature. If someone had a page explaining something in Wittgenstein or in nuclear physics, he couldn't change the language to make it accessible to slow-learners or children without destroying the content.
And goodness knows why JAWS reads stylesheets. Currently you can hide them from it with @import. I've seen rumours that the next version will support @import - are they crazy or something?
Michael
Share:
| Michael wrote: |
|
And goodness knows why JAWS reads stylesheets. Currently you can hide them from it with @import. I've seen rumours that the next version will support @import - are they crazy or something? |
The imported stylesheet might contain Aural CSS?
Share:
| Michael wrote: |
| I've seen rumours that the next version will support @import - are they crazy or something? |
Crack rock. Definitely smoking the crack rock ...
Share:
| Michael wrote: |
|
But a blind user, for example, might not get the content, if we don't accomodate his software. And even if a new version of a screenreader fixes a problem, it won't be free to download. There's a small user-base and there's been no screen-reader war to kill the price-tag. |
I take your point but there's a few things I would counter with:
Firstly, we're in effect talking about making special cases out of people with disabilities all over again if we do this, or agree to ignore it. We're now as near as we've ever been to having a situation where the standards exist, the browser manufacturers are getting more onboard with every release and yet we're still having to discuss workarounds for buggy software- the fault is not the users and neither is it the designers- if we agree that standards are the way forward then we need to either accept them and adhere to them or agree not to until a better one comes along. Its ludicrous IMO that screenreaders can't tell where one anchor closes and another one starts- its a crystal clear tag.
Share:
| Kev wrote: |
| Its ludicrous IMO that screenreaders can't tell where one anchor closes and another one starts- its a crystal clear tag. |
I'll stick my neck out here and say that, as far as I know, that's entirely a legacy issue for old screen readers, though I'm willing to be shown I'm wrong on this. To the best of my knowledge, all or most recent screen reader versions can handle adjacent links as long as they're properly marked up (i.e. all closing tags in place) or contained in separate table cells, since most recent screen readers interpret the HTML code as well as read the screen content. It's the old screen readers that literally "read the screen" which had problems.
Having said that, though, I'd suggest that, visually, links with nothing between them can be a problem in text browsers like Lynx. Depending on how you've got Lynx configured, it can be very difficult to tell adjacent links apart if there are no separating characters (like "|" for example).
Share:
I don't know about screen readers, I certainly have a problem distinguishing adjacent links within a paragraph!
Looks like it could be one link to me:
Here is some text talking about why adjacent links can be annoying.
Although I agree that screen readers need to take responsibility for handling it, it still needs to be considered best practice not to have adjacent links.
I am not counting list items, tables cells etc as adjacent links, I'm talking about:
<a href="#">foo</a> <a href="#">bar</a>
Accessify Forum Administrator ~ Nigel Peck / MIS Web Design
"Everything I say is not meant to be set in stone" - Van Morrison
Share:
Hi all, kinda new to the forum and generally fairly new to web accessibility (being thrown in at the deep at work has prompted it ) but I'm a big advocate of web standards and the like so finding this place where the 2 seem to be quite entagled is great!
Anyway, I'd just like offer support to this
[quote=Nigel] it still needs to be considered best practice not to have adjacent links.[/quote]
Spot on, your not the only one who has a bit more difficulty reading adjacent links in paragraphs. Are they really needed? Would it not be considered a general usability issue, let alone an accessibility issue to have them so close together? Especially when some designers insist on making links look quite like standard body text, even more so with visited links which tend to be subtler than others.
The fact that some screen readers have trouble with it may be a slight failing on their part, but really, good content probably shouldn't have links in that kind of format.
Share:
Oh yeah, hence the space and the couple of :: between the links in my sig
Share:
Although this may seem to be painfully obvious, all people need to do is rewrite their sentence if there are two links adjacent to each other.
Share:
I think there needs to be a seperation of the two definitions of 'adjacent' here. I think a few people are taking about the example posted by Nigel above, which I agree is annoying in the extreme- what I'm talking about is where links aer considered adjacent even if on a seperate line- see my sig for what I mean. This action by screenreaders is IMO, stupid and needs fixing- not only is a seperate tag, its on another line so is seperated therefore by both a space and a carriage return.
Share:
Ah, fair point Kev, if screen readers are screwing that up then yeah, that should be addressed.
Would those links not normally be separated by a <br/> or a new list item or even be set as display:block (an therefore shouldn't be treated as continuous text anyway should it?)? I've only used JAWS and HAL/SuperNOVA in very small doses so far to know much about them, but do they not treat the above as breaks in the flow of the text?
Share: