E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: John Foliot - Stanford Online Accessibility Program
Date: Mon, Jan 22 2007 1:20PM
Subject: aural CSS (was Alt text (was VIKI - text transcodeing))
No previous message | Next message →

Keith Parks wrote:
>
> Too bad you can't use the pause-before and pause-after aural css
> rules on the ALT content.

Too bad we can't get a mainstream browser or screen reader to support aural
CSS...

JF

From: Phil Teare
Date: Mon, Jan 22 2007 1:30PM
Subject: Re: aural CSS (was Alt text (was VIKI - text transcodeing))
← Previous message | Next message →

This is a great point.

This is pretty much down to the fact that its a step too far to expect the
average web developer to care about learning Aurall CSS.

I love the idea, its just too involved to work in practice...

Something I think that is equaly unlikely to ever be implimented by most web
devs, but that would be great if they did, would be phoneme tags to state
how to pronouce names. The difference here would be that even if only a
percentage of news sites and blogs did this, it could be used to build the
phonetic dictionaries of engines. So the next site you went to that didn't
bother, would benefit from the one that did.

Has there been an attempt to standardize this (I'm guessing several...)

Chrs
Phil

On 22/01/07, John Foliot - Stanford Online Accessibility Program <
= EMAIL ADDRESS REMOVED = > wrote:
>
> Keith Parks wrote:
> >
> > Too bad you can't use the pause-before and pause-after aural css
> > rules on the ALT content.
>
> Too bad we can't get a mainstream browser or screen reader to support
> aural
> CSS...
>
> JF
>
>
>

From: Jared Smith
Date: Mon, Jan 22 2007 2:50PM
Subject: Re: Alt text (was VIKI - text transcodeing)
← Previous message | Next message →

On 1/22/07, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
> With regards to the square brackets, surely this is something that should be left up to the user agent?

I'm really struggling with the idea of the square brackets also. This
is certainly a user agent issue, not the developer's problem. And it
certainly seems to go against the specs. Alt text is an alternative,
not an alternative with additional markers to make it sound or look better in
user agents that don't know how to provide a differentiation between text and
alt text.

> Still, I do find screen reader's habit of reading images as part of the document flow rather unintuitive (i.e. without pause unless you use punctuation).

Inline images should be read this way, but MOST images should not.
I've always been somewhat bothered that most screen readers do not
identify images. I think this likely stems from most pages not having
alt text at all. Surely images with alt text should be identified as
an image with either the word "image" or a beep or a different
voice... or something. It certainly should not be the developers
burden to identify images or to fix reading issues in user agents.

Jared Smith
WebAIM.org

From: John Foliot - Stanford Online Accessibility Program
Date: Mon, Jan 22 2007 3:30PM
Subject: Re: Alt text (was VIKI - text transcodeing)
← Previous message | Next message →

Jared Smith wrote:
> On 1/22/07, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
>> With regards to the square brackets, surely this is something that
>> should be left up to the user agent?
>
> I'm really struggling with the idea of the square brackets also. This
> is certainly a user agent issue, not the developer's problem. And it
> certainly seems to go against the specs.

In what way Jared? As non-voicing "punctuation", how does the inclusion of
square brackets go against the spec.? (Serious question - not trying to be
facetious or difficult)

I'm not saying that this is a perfect solution, but I believe it addresses a
situation that exists today and does minimal to zero harm to other users
(i.e. screen reader users). In fact, if you are prepared to give it just a
little latitude, there are 2 Priority 3 checkpoints in WCAG which might
suggest that this is in fact 'a good thing':

13.8 Place distinguishing information at the beginning of headings,
paragraphs, lists, etc. (does an image fit within "etc."? Does wrapping alt
text within square brackets "distinguish" it from standard inline text?)

14.2 Supplement text with graphic or auditory presentations where they
will facilitate comprehension of the page.
(does placing alt text within square brackets "facilitate comprehension" of
a page in text-only browers?)

> Alt text is an alternative,
> not an alternative with additional markers to make it sound or look
> better in user agents that don't know how to provide a
> differentiation between text and alt text.

I don't disagree, but currently text-only browsers *do not* make the
distinction, and even if they did, how should they/would they? Can't use
color alone (this surely breaks the spec), and the equiv of <em> or <strong>
is semantically incorrect. I originally commented on this as the new VIKI
tool was doing the same thing (using square brackets) for alt text as part
of it's re-formatting.

I have proposed a possible solution - it is by no means definitive, or even
"correct", but rather it is a suggestion. I have been quietly using it for
about 8 months now, to zero feedback negative or positive. I agree with
Jared that this should *not* be our problem, but currently it is - text-only
browsers do not distinguish between alt text and standard in-line text,
which can lead to confusion and "poor rendering" on screen.


> Surely images with alt text should be identified as
> an image with either the word "image" or a beep or a different
> voice... or something. It certainly should not be the developers
> burden to identify images or to fix reading issues in user agents.

Perhaps others on the list could chime in with other ideas? In the absence
of text-only browsers rendering alternative text "differently" from standard
page text, is there a best practice? Is there a recommendation that
user-groups could advocate to developers of such tools? Is it something
that we as content developers should even worry about?

Cheers!

JF

From: Patrick H. Lauke
Date: Mon, Jan 22 2007 3:40PM
Subject: Re: Alt text (was VIKI - text transcodeing)
← Previous message | Next message →

John Foliot - Stanford Online Accessibility Program wrote:

> Perhaps others on the list could chime in with other ideas? In the absence
> of text-only browsers rendering alternative text "differently" from standard
> page text, is there a best practice? Is there a recommendation that
> user-groups could advocate to developers of such tools? Is it something
> that we as content developers should even worry about?

Not sure if this would work universally, but: avoid inline images
wherever possible and instead put them in their own block-level element?

P
--
Patrick H. Lauke

From: Phil Teare
Date: Mon, Jan 22 2007 4:00PM
Subject: Re: Alt text (was VIKI - text transcodeing)
← Previous message | Next message →

>
> I have not seen any other UA that actually "separates" alt text from
> standard text (that is, until I saw Phil's VIKI rendering), and as you
> have
> noted, this can occasionally make ALT text 'read funny', not only for
> screen
> readers, but for other text-only UAs. As I mentioned earlier, my use of
> the
> square bracket then is mostly an experiment (which has started to become
> part of my regular development flow), to try and address this observation.
> It does not add significantly to any user "load", and in certain
> circumstances seems to improve the overall user experience. I have not
> had
> any negative feedback (but I've not had any positive either, so I guess
> the
> jury is still out).



The square brackets were inherited from the Loband screen scraper that VIKI
sits on. I like it. Its not perfect. But as VIKI is designed to be the
reader, as well as the Transcoder, the format used is less critical. And it
matters little if they are read perculiarly by other readers. As... its not
meant for other readers.

BTW I've made a new addition to VIKI re forms. Now if you press F8 on an
input element, she steps out so you can carry on using hotkeys again. That
was the last a BIG whole in her functionality I think. Obviously tons to
do... But I think she's good and useful to many now.

Still not much feedback from this forum...

Anyone used it yet?

Cheers
Phil

--
Phil Teare,
Technical Director & Lead Developer,
http://www.talklets.com from Textic Ltd.
(44) [0] 77 68479904

From: Jared Smith
Date: Mon, Jan 22 2007 4:10PM
Subject: Re: Alt text (was VIKI - text transcodeing)
← Previous message | Next message →

On 1/22/07, John Foliot - Stanford Online Accessibility Program wrote:
> In what way Jared? As non-voicing "punctuation", how does the inclusion of
> square brackets go against the spec.? (Serious question - not trying to be
> facetious or difficult)

I think that adding additional information into such elements, even
though it may not be violating the specs, certainly goes against the
spirit of the guidelines. While an extreme example, if alt="[alt
text]" is alright, why not make it
alt="[[[[[***!!!!~~~~ ALT TEXT ~~~~!!!!***]]]]]]" to REALLY highlight
and draw attention to this VERY important alt text? All of the
characters are not read by screen readers, so it's OK, right?

A similar conversation is occurring elsewhere regarding microformats
use of <abbr> to store computer readable date/time. Yes, it's within
spec, but it certainly does not seem to be a very true and friendly
use of the element.

Also, there is no rule that makes the brackets (or any other
characters) non-voicing. The one (or maybe two) major screenreaders
just happen to not voice it. What about future screen readers? Less
popular screen readers? Other text browsers? It just seems like such a
hack to me.

> I don't disagree, but currently text-only browsers *do not* make the
> distinction, and even if they did, how should they/would they?

Brackets - just as you've prescribed would work nicely.

> I agree with
> Jared that this should *not* be our problem, but currently it is - text-only
> browsers do not distinguish between alt text and standard in-line text

But I say, let's MAKE IT the user agent's problem. Don't you think it
would be easier and more logical to get a couple of text-only browser
developers to provide this distinction, rather than to get millions of
web developers and dozens of design tools to provide this distinction
within content? Gone should be the days when developers account for
the user agents poor implementation of accessibility and
specifications. Yes, we're currently far from this point, but if we
want accessibility to become more widespread, we need it to be easier.
And hacking our way around user agent weaknesses is not the way for
this to happen.

<slightly off-topic rant>
Perhaps what we really need is a strong open-source accessibility
movement where the community and standards drives screen reader and
other assistive technology innovation, rather than hoping and waiting
for the existing industry to be responsive. This could certainly drive
down cost and increase innovation. Look at what Firefox has done to
the browser market - imagine if those efforts had been solely on
assistive technology.
</slightly off-topic rant>

Jared

From: John Foliot - Stanford Online Accessibility Program
Date: Mon, Jan 22 2007 4:30PM
Subject: Re: Alt text (was VIKI - text transcodeing)
← Previous message | Next message →

Jared Smith wrote:
>
> I think that adding additional information into such elements, even
> though it may not be violating the specs, certainly goes against the
> spirit of the guidelines.

Perhaps, but I also stand behind those two Priority 3 guidelines in terms of
attempting to ensure clarity of content. Sure, it's a bit of a stretch, but
it is also "in the spirit"...

> While an extreme example, if alt="[alt
> text]" is alright, why not make it alt="[[[[[***!!!!~~~~ ALT TEXT
> ~~~~!!!!***]]]]]]" to REALLY highlight and draw attention to this
> VERY important alt text? All of the characters are not read by screen
> readers, so it's OK, right?

LOL - Jared, of course not, certainly not like that - and neither is USING
ALL CAPS TO GET A POINT ACROSS. But don't confuse exaggeration with
striving for clarity - they may be at times similar, but they are not the
same.

>
> A similar conversation is occurring elsewhere regarding microformats
> use of <abbr> to store computer readable date/time. Yes, it's within
> spec, but it certainly does not seem to be a very true and friendly
> use of the element.

While I have not seen this thread, I do concur that using the ISO date
standard that microformats insists on is the only way to be truly machine
interoperable (it's a STANDARD!), however it's not that user-friendly to
print out. Whether or not the <abbr> element is correct or not... I
probably would stand with you, and suggest <span> instead. But this strays
somewhat...

> Also, there is no rule that makes the brackets (or any other
> characters) non-voicing. The one (or maybe two) major screenreaders
> just happen to not voice it. What about future screen readers? Less
> popular screen readers? Other text browsers? It just seems like such
> a hack to me.

Well, perhaps. I like to think of it as a "work-around", one that
intersects pragmatism with altruism, but yes, it is a hack. But for now, if
200-300 committed web accessibility-minded developers adopted it as a
best-practice, it might start to see some up-take, and gain a position where
the user-agent community might even consider implementing it into their
tools. Right now, I suspect that they don't even know or acknowledge that
there *is* an issue, let alone how to fix it.

>
> But I say, let's MAKE IT the user agent's problem. Don't you think it
> would be easier and more logical to get a couple of text-only browser
> developers to provide this distinction, rather than to get millions
> of web developers and dozens of design tools to provide this
> distinction within content?

Agreed 101%. However, given the relatively small user-base of both
text-only browsers, and users, this may be harder than it sounds. I suppose
a Firefox extension could be written for when users disable images, and
Opera's user-scripting capacities could perhaps also come into play. If it
gained traction then maybe Internet Explorer would also follow. But again,
first we as a community of accessibility committed developers need to show
that there is an issue, and that it can be fixed relatively easily.

> Gone should be the days when developers
> account for the user agents poor implementation of accessibility and
> specifications. Yes, we're currently far from this point, but if we
> want accessibility to become more widespread, we need it to be
> easier. And hacking our way around user agent weaknesses is not the
> way for this to happen.

Fundamentally, I agree with you. But meanwhile, the problem still exists,
and while we can hope 'for the day', we also need to live (and work) for
*today*. It's a chicken or egg problem...

Cheers!

JF

From: Léonie Watson
Date: Tue, Jan 23 2007 2:30AM
Subject: Re: Alt text (was VIKI - text transcodeing)
← Previous message | No next message

Alastair Campbell wrote:

"I believe (and Léonie will elbow me if I'm wrong) that square brackets aren't read by Jaws on default settings..."

For Jaws at least, the default punctuation level is "Most", which would read out square brackets. It's reasonable to assume that many screen reader users will alter the default punctuation level to something less intrusive though.

In Jaws at least, the punctuation settings are among the easier configurations to find, housed along with the speech rate and pitch settings, which many people also adapt fairly early on in their time using a screen reader.

Regards,
Léonie.