Re: <span> within a word any issue for screen readers?

Phill Jenkins wrote:

>
>
> My point here is that there are some immediate bugs in screen reader 
> behavior that could be fixed.  Simple examples like:
> Acc<span>e</span>ssibility
> should not be pronounced as though it were written: Acc e ssibility 
> (ie, as three distinct words).
> But there are also some missing specifications from the WCAG, UAAG, 
> and HTML & CSS specifications, and more importantly, a missing 
> specification that describes the way for the author to specify how to 
> pronounce words that have all this nonstructural markup in the middle. 
>  Geoff wrote:
>         If SPAN element is empty of attributes ignore
>        else apply rules appropriately.
> What rules?   If <span> element has some visual styling, should it be 
> ignored?  How should it be ignored?  Should bold's be ignored, but 
> underlined's be spoken after wards?  Where is that a rule - or best 
> practice written?
>

Logic;

If SPAN element is empty of attributes ignore applying any formatting, 
as it carries no structural meaning in itself.

If the attributes LANG or DIR are applied in this instance I can't see a 
valid case for their use, and in this case the developer is going to 
throw up an unexpected exception for the user agent to handle.  Such a 
case should never be implemented by the web developer IMHO.

If the attributes CLASS or ID are applied they should still not effect 
the screen reading of the text, unless there is some audio.css 
instructions, also something I can't see why it would be implemented by 
the web developer.

What I don't know is that even if the screen reader didn't have a 
problem with reading a word with an inline SPAN element, how it would 
communicate via the screen reader the presence of the accesskey.  That 
could be a problem.  I'll have to test it.

Still, IMHO, this is a bug in screen readers.

I don't think anyone should be using <U></U> as they are deprecated.

----------------
Geoff Deering

Received on Monday, 9 January 2006 20:08:19 UTC