E-mail List Archives

Search E-mail List Archives for

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

From: John Foliot - WATS.ca
Date: Thu, Mar 23 2006 7:50AM
Subject: FW: HTML - <abbr> and <acronym> settings
No previous message | Next message →

Thursday, March 23, 2006 7:22 AM wrote:
> User subject description is = HTML - <abbr> and <acronym> settings
>
> Comment or suggestion = Hello,
> I am an active "Web Accessibility" proponent and developer, and I am
> writing to ask that the method by which JAWS handles the <abbr> and
> <acronym> elements be re-considered. The current set-up (either
> always on or always off) introduces potential frustration and poor
> usability for JAWS users. Ideally, the better solution would be that
> the "expansion" of either element (i.e. - the reading of the Title
> attribute) would be activated by a keystroke combination, so that the
> end user can "expand" the complete definition "on-the-fly" by choice.
> I am not sure how possible this is, but it would be a welcome
> enhancement to your product. There is an interesting List-serve
> thread currently underway at:
> http://webaim.org/discussion/mail_thread.php?thread=2799
> that is discussing this very issue.
>
> In a perfect world, a response that I could share back to this list
> (or a direct response from Freedom Scientific to the list) would be
> both appreciated and welcome.
>
> Thank you.
>
> John Foliot
> WATS.ca - Web Accessibility Testing and Services http://www.wats.ca
>
>
>
> * * * End of document * * *



Bryan Carver wrote:
> Hello John,
> Thank you very much for your suggestion. It is good feedback like
> this from our customers, that allows us to continue to make our
> products the best they can be. I will definitely pass your
> suggestion along to our product management team.
> I am sure if they have additional questions they will be in touch
> with you. Please do not hesitate to let me know if there is anything
> else I can do for you.
>
> Regards,
>
> Bryan Carver
> Director of Technical Support
> Freedom Scientific
>

From: Kynn Bartlett
Date: Thu, Mar 23 2006 8:00AM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

On 3/23/06, John Foliot - WATS.ca < = EMAIL ADDRESS REMOVED = > wrote:
>
> Bryan Carver wrote:
> > Hello John,
> > Thank you very much for your suggestion. It is good feedback like
> > this from our customers, that allows us to continue to make our
> > products the best they can be. I will definitely pass your
> > suggestion along to our product management team.
> > I am sure if they have additional questions they will be in touch
> > with you. Please do not hesitate to let me know if there is anything
> > else I can do for you.



I love form letter responses.

--Kynn

From: John Foliot - WATS.ca
Date: Thu, Mar 23 2006 9:20AM
Subject: RE: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

Kynn Bartlett wrote:
> On 3/23/06, John Foliot - WATS.ca < = EMAIL ADDRESS REMOVED = > wrote:
> Bryan Carver wrote:
>> Hello John,
>> Thank you very much for your suggestion. It is good feedback like
>> this from our customers, that allows us to continue to make our
>> products the best they can be. I will definitely pass your
>> suggestion along to our product management team.
>> I am sure if they have additional questions they will be in touch
>> with you. Please do not hesitate to let me know if there is anything
>> else I can do for you.
>
>
> I love form letter responses.
>
> --Kynn

Right, but what have *you* done to try and fix the "problem". It may be
a canned response, but if enough people ask for the same feature, it may
in fact get through and go beyond the circular file.

Let's try being positive instead of negative why don't we?

JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist
WATS.ca - Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053

From: ben morrison
Date: Thu, Mar 23 2006 9:40AM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

On 3/23/06, John Foliot - WATS.ca < = EMAIL ADDRESS REMOVED = > wrote:
> Thursday, March 23, 2006 7:22 AM wrote:
> > User subject description is = HTML - <abbr> and <acronym> settings
> >
> > Comment or suggestion = Hello,
> > I am an active "Web Accessibility" proponent and developer, and I am

....

> >
> > In a perfect world, a response that I could share back to this list
> > (or a direct response from Freedom Scientific to the list) would be
> > both appreciated and welcome.
> >
> > Thank you.
> >
> > John Foliot
> > WATS.ca - Web Accessibility Testing and Services http://www.wats.ca

That's exactly what we all should be doing instead of debating why the
products don't work.

ben

From: Jared Smith
Date: Thu, Mar 23 2006 10:20AM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

ben morrison wrote:
> That's exactly what we all should be doing instead of debating why the
> products don't work.

But this does bring up the question that I have been wondering for some
time - why aren't the screen reader developers ever in these discussions???

By my count, there are two people from the major screen reader development
companies on this list. Two. I'm on the W3C list, the WSG list, and many
others and have yet to see a post from the people that know this product
best, and more importantly, are making the decisions about how it should
work. While it's important that WE have these conversations and pass on
our findings on to them, one would think that their involvement in these
discussions would certainly lead to more action and ultimately better
accessibility.

To demonstrate this problem, I was recently at a major disability
conference and had a discussion with the development lead for one of the
three major screen readers. I brought up a bug that is in screen reader,
and has been for some time. In reply to my comments, he replied, and these
are just about his exact words, "It's not a bug unless it works correctly
in the other two screen readers and not in ours. Document that it's a
feature of those two screen readers and not ours, and then we'll fix it."
Am I crazy for being a little frustrated by this attitude?

But again, here I am being counterproductive, so I'm going to get on the
elevator, go downstairs to another major disability conference, and bring
up this specific issue with their developers right now. I'm glad I could
do my part, but I still wonder what we can do to get them to come to us
instead.

Jared Smith

From: Karl Groves
Date: Thu, Mar 23 2006 10:30AM
Subject: RE: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

> To demonstrate this problem, I was recently at a major
> disability conference and had a discussion with the
> development lead for one of the three major screen readers. I
> brought up a bug that is in screen reader, and has been for
> some time. In reply to my comments, he replied, and these are
> just about his exact words, "It's not a bug unless it works
> correctly in the other two screen readers and not in ours.
> Document that it's a feature of those two screen readers and
> not ours, and then we'll fix it."
> Am I crazy for being a little frustrated by this attitude?
>

Crazy? Nope. You have every right to be frustrated, not just at the
attitude, but at the entire notion that W3C recommendations aren't followed
properly by products designed for use on the Web.

But look at it from their point of view. I believe everyone on this list
already understands this: Making further changes to a product will require
time and money. The "cost" of that time and money is not just related to
that which is required to make the changes, but also adds to the increased
delay and cost of developing other products.

In other words, investing 100 hours to add a feature not only costs 100
hours of time and 100 x hourly rate for developers, but it delays other
products by 100 hours and piggybacks the labor cost on top of all other
products under development.

Don't get me wrong. I think they should have gotten it right the first time.
But since that's obviously not the case, we shouldn't expect someone to snap
their fingers and it'll get fixed. Their job is to make money. If the
diversion funds & manpower doesn't add to the bottom line, it is
understandable that they'd be disinclined to be in a hurry for new features
& bug fixes.


Karl L. Groves

From: Austin, Darrel
Date: Thu, Mar 23 2006 11:50AM
Subject: RE: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

> Don't get me wrong. I think they should have gotten it right
> the first time.
> But since that's obviously not the case, we shouldn't expect
> someone to snap their fingers and it'll get fixed. Their job
> is to make money. If the diversion funds & manpower doesn't
> add to the bottom line, it is understandable that they'd be
> disinclined to be in a hurry for new features & bug fixes.

And not to veer this too far OT, but if one does get upset with software
comapanies having that attitude, the solution is to volunteer some
energy towards one of the open source alternatives.

-Darrel

From: Daisy
Date: Thu, Mar 23 2006 12:10PM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

I don't know the mechanics behind it but would it be possible to provide a
screenreader service in a similar model to browsercam? I see from mailing
lists that folk who wouldn't previously have dreamed of testing their
designs in anything other than IE on a PC are now realising the benefits of
testing it on other browsers and I wonder if a similar movement could happen
with a more accessible way of seeing a screenreader in action.

-Daisy


On 3/23/06, Kynn Bartlett < = EMAIL ADDRESS REMOVED = > wrote:
>
> On 3/23/06, Austin, Darrel < = EMAIL ADDRESS REMOVED = > wrote:
>
> > And not to veer this too far OT, but if one does get upset with software
> > comapanies having that attitude, the solution is to volunteer some
> > energy towards one of the open source alternatives.
>
>
> Do open source screenreaders exist?
>
> Are they used by anyone?
>
> It may be more productive to petition the screenreader makers which have
> products which are actually used. If there's a 1% chance you can have a
> positive effect by nagging someone via email, and affect 50% of the
> screenreader users, or there's 100% chance that you'd have a positive effect
> by working on open source code that's used by...50 people...which is the
> better choice?
>
> --Kynn
>
>
>
>
>
>
>
>
>
>


--
Daisy
http://chasingdaisy.typepad.com

From: Austin, Darrel
Date: Thu, Mar 23 2006 12:50PM
Subject: RE: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

> It may be more productive to petition the screenreader makers
> which have products which are actually used.

As was stated, a lot of software companies are in the business of making
money.

If their product is the one that is already used by the most, there's no
reason for them to care about any petition.

They would, of course, care about competition.

IMHO, of course.

(BTW, I'm not specifically saying screen reader software companies are
like this...just saying in general...)

-Darrel

From: Kynn Bartlett
Date: Thu, Mar 23 2006 1:30PM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

On 3/23/06, Daisy < = EMAIL ADDRESS REMOVED = > wrote:
>
> I don't know the mechanics behind it but would it be possible to provide a
> screenreader service in a similar model to browsercam?
>

Well, the problem is that screenreaders are interactive, so you can't just
dump a screenshot or the like. Screenreaders are a way of navigating through
the content, and in fact that's where a lot of the problems result.

The solution also isn't "just test with a screenreader" because most
developers won't spend the time necessary to learn to how to use a
screenreader, and are thus unable to use them to evaluate web sites. Too
many false positives and false negatives will result.

(By "spend the time necessary" I mean at least 2 weeks straight of using a
screenreader, with monitor turned off, as your only means of accessing a
computer.)

Screenreader demos are good for raising awareness -- most web developers
have never "heard" a web page before -- but they're not good for testing
purposes. Web developers should be aware of how and why screenreaders work,
but they don't actually need screenreader output, which would be worthless
to most of them.

--Kynn

From: Kynn Bartlett
Date: Thu, Mar 23 2006 2:30PM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

On 3/23/06, Austin, Darrel < = EMAIL ADDRESS REMOVED = > wrote:
>
> And not to veer this too far OT, but if one does get upset with software
> comapanies having that attitude, the solution is to volunteer some
> energy towards one of the open source alternatives.


Do open source screenreaders exist?

Are they used by anyone?

It may be more productive to petition the screenreader makers which have
products which are actually used. If there's a 1% chance you can have a
positive effect by nagging someone via email, and affect 50% of the
screenreader users, or there's 100% chance that you'd have a positive effect
by working on open source code that's used by...50 people...which is the
better choice?

--Kynn

From: Austin, Darrel
Date: Thu, Mar 23 2006 2:40PM
Subject: RE: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

> I think you might not understand how entrenched the current
> screenreaders are, how difficult it is for a new software
> company to come out with a new product, how hard it can be to
> test and debug a screenreader, and how hard it is to gain
> acceptance within the community ( e.g. marketing to the
> disability user base).

I'm jaded. I've had to work with and buy software for ages that just
plain sucks. The fact that software sucks really has no correlation to
its market share. I've found that bad softare is actually accepted as
the norm in a lot of corporations. So, it's a catch 22: The customer
says 'yes, the software sucks, but it's the standard, so we bought it'
and the software company says 'yes, our software sucks, but people buy
it, so why change it?'.

>From what I've seen, the only way to get out of that downword spiral is
to have some competition come along that can chip away at the
marketshare. IE didn't improve until Firefox forced it to. QuarkXPress
didn't improve until InDesign forced it to. Word didn't improve
until...well...Word still sucks.

Anyways, I'm getting way OT now...

-Darrel

From: Kynn Bartlett
Date: Thu, Mar 23 2006 2:50PM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

On 3/23/06, Austin, Darrel < = EMAIL ADDRESS REMOVED = > wrote:
>
> > It may be more productive to petition the screenreader makers
> > which have products which are actually used.
>
> As was stated, a lot of software companies are in the business of making
> money.
> If their product is the one that is already used by the most, there's no
> reason for them to care about any petition.
> They would, of course, care about competition.
> IMHO, of course.
> (BTW, I'm not specifically saying screen reader software companies are
> like this...just saying in general...)


Since the discussion is about open source...

I think you might not understand how entrenched the current screenreaders
are, how difficult it is for a new software company to come out with a new
product, how hard it can be to test and debug a screenreader, and how hard
it is to gain acceptance within the community (e.g. marketing to the
disability user base).

If you can do that with people working for free, more power to you; but it's
really not as simple as just saying "if you don't like the current
screenreaders, write your own." Even if you could write one, you'd have
many other huge obstacles that can't be solved by open source code writing.

I think it makes more sense to recommend fixing screenreaders than it does
to imagine that you're going to a write a free, open source screenreader
that will put market pressure on JAWS (or whoever) and possibly get them
worried over the competition. Existing screenreaders are heavily entrenched
(for a variety of reasons) and it's hard for new, for-profit companies with
investment money to break into the field.

--Kynn

From: Daisy
Date: Thu, Mar 23 2006 3:00PM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

Kynn, I should have said that browsercam also offers remote access on a
variety of platforms (not just screenshots of pages taken in various
browsers); I had the image of being able to remotely access a platform with
a screenreader enabled but I appreciate your point that there is a learning
curve to the use of a screenreading software, something I'd not considered
before.



On 3/23/06, Kynn Bartlett < = EMAIL ADDRESS REMOVED = > wrote:
>
> On 3/23/06, Daisy < = EMAIL ADDRESS REMOVED = > wrote:
>
> > I don't know the mechanics behind it but would it be possible to provide
> > a screenreader service in a similar model to browsercam?
> >
>
> Well, the problem is that screenreaders are interactive, so you can't just
> dump a screenshot or the like. Screenreaders are a way of navigating through
> the content, and in fact that's where a lot of the problems result.
>
> The solution also isn't "just test with a screenreader" because most
> developers won't spend the time necessary to learn to how to use a
> screenreader, and are thus unable to use them to evaluate web sites. Too
> many false positives and false negatives will result.
>
> (By "spend the time necessary" I mean at least 2 weeks straight of using a
> screenreader, with monitor turned off, as your only means of accessing a
> computer.)
>
> Screenreader demos are good for raising awareness -- most web developers
> have never "heard" a web page before -- but they're not good for testing
> purposes. Web developers should be aware of how and why screenreaders work,
> but they don't actually need screenreader output, which would be worthless
> to most of them.
>
> --Kynn
>
>
>
>
>
>
>
>
>
>


--
Daisy
http://chasingdaisy.typepad.com

From: Tim Beadle
Date: Fri, Mar 24 2006 2:10AM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

On 23/03/06, Karl Groves < = EMAIL ADDRESS REMOVED = > wrote:
> Don't get me wrong. I think they should have gotten it right the first time.
> But since that's obviously not the case, we shouldn't expect someone to snap
> their fingers and it'll get fixed. Their job is to make money. If the
> diversion funds & manpower doesn't add to the bottom line, it is
> understandable that they'd be disinclined to be in a hurry for new features
> & bug fixes.

The collective authors of the web (all n 100s of millions of us)
"should have gotten it right first time". I suspect that the current
brokenness of the major screen readers is a largely a function of the
brokenness of many of the web sites out there. They have to jump
through hoops to extract meaning from sites where it's not evident.
The recent trend towards meaningful, semantic HTML doesn't help one
jot if the AT doesn't understand...

Tim

From: Karl Groves
Date: Fri, Mar 24 2006 7:50AM
Subject: RE: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

(Apologies for the top post. I hate the way IE quotes HTML formatted
e-mails)

Yup. I do agree with Tim.
UA's in general, be they graphical, aural, or something else, are unlikely
to be in a hurry to get the specs right if web authors aren't in a hurry,
too.

Let's face it. If I program something with PHP and I mess it up, the entire
application won't work. In fact, I don't know of ANY programming language
that works if you mess things up as bad as people mess up their markup.

We're in a vicious circle - user-agents don't support specs because authors
don't, either. Authors aren't inclined to follow specs if it renders in
their favorite user-agents.

What a great vision it would be if all of a sudden browsers refused to
display invalid markup (and what a great pay raise we'd get when our sites
were among the unfortunate few that actually still worked!)

Karl L. Groves
User-Centered Design, Inc.
Office: 703-729-0998
Mobile: 443-889-8763
E-Mail: = EMAIL ADDRESS REMOVED =
Web: http://www.user-centereddesign.com
<http://www.user-centereddesign.com/>;




_____

From: Kynn Bartlett [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, March 24, 2006 9:27 AM
To: WebAIM Discussion List
Cc: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] FW: HTML - <abbr> and <acronym> settings


On 3/24/06, Tim Beadle < = EMAIL ADDRESS REMOVED = > wrote:


The collective authors of the web (all n 100s of millions of us)
"should have gotten it right first time". I suspect that the current
brokenness of the major screen readers is a largely a function of the
brokenness of many of the web sites out there. They have to jump
through hoops to extract meaning from sites where it's not evident.
The recent trend towards meaningful, semantic HTML doesn't help one
jot if the AT doesn't understand...


Excellent point.

It's all really a mess...and we need to be careful about placing too much
blame squarely on one group (e.g. screenreader developers). I think both
you and Karl are saying something similar.

--Kynn

From: Tim Beadle
Date: Fri, Mar 24 2006 8:00AM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

On 24/03/06, Karl Groves < = EMAIL ADDRESS REMOVED = > wrote:
> What a great vision it would be if all of a sudden browsers refused to
> display invalid markup (and what a great pay raise we'd get when our sites
> were among the unfortunate few that actually still worked!)

That version/vision of the WWW would be technically excellent but
rather limited. The growth of the web stems from HTML's low barrier to
entry. You don't *have* to put your tags in the right order (or even
the right place!) for your page to work.

If Joanne Public, Amateur Web Publisher got Mozilla's
beige-screen-of-xml-parsing-death every time she misplaced a tag, she
would soon find something less challenging to do instead. HTML is,
therefore, a double-edged sword. It's easy, but therefore open to
abuse and neglect.

It would be nice if major authoring tools (*cough* Apple iWeb, Google
Page Creator *cough*) created valid, semantic, accessible code, but
it's not an easy thing to achieve. If Google can solve search, I'm
sure they could solve WYSIWYG -> semantic/structured HTML.

Tim

From: Christian Heilmann
Date: Fri, Mar 24 2006 8:10AM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

> It would be nice if major authoring tools (*cough* Apple iWeb, Google
> Page Creator *cough*) created valid, semantic, accessible code, but
> it's not an easy thing to achieve. If Google can solve search, I'm
> sure they could solve WYSIWYG -> semantic/structured HTML.

Having dabbled with some WYSIWYG editors myself I must say that is not
that easy and is quite a different task from writing a search /
spidering algorhithm.

The whole idea of the web and contributing to it as it is is flawed
because of the low threshold you have rightfully brought up. WYSIWYG
does not only create bad markup in a lot of cases but also bad
content.

I've spend far too many hours telling editors that "click the links in
the blue panel on the left" is not good page copy, and I have found
one project where that piece of content is still in there although the
navigation is now a green strip on the top.

Content does not get better by adding smileys animations or laying it
out while you type it, writing and layout are different skill sets
that don't always mix.

That said, I must say I am impressed how clean the code of Googlepages
is compared to other products (contained in CMS costing >

From: Kynn Bartlett
Date: Fri, Mar 24 2006 8:20AM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

On 3/24/06, Tim Beadle < = EMAIL ADDRESS REMOVED = > wrote:
>
> The collective authors of the web (all n 100s of millions of us)
> "should have gotten it right first time". I suspect that the current
> brokenness of the major screen readers is a largely a function of the
> brokenness of many of the web sites out there. They have to jump
> through hoops to extract meaning from sites where it's not evident.
> The recent trend towards meaningful, semantic HTML doesn't help one
> jot if the AT doesn't understand...


Excellent point.

It's all really a mess...and we need to be careful about placing too much
blame squarely on one group (e.g. screenreader developers). I think both
you and Karl are saying something similar.

--Kynn

From: Patrick H. Lauke
Date: Fri, Mar 24 2006 11:30AM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | Next message →

Karl Groves wrote:

> We're in a vicious circle - user-agents don't support specs because
> authors don't, either. Authors aren't inclined to follow specs if it
> renders in their favorite user-agents.

Assistive technology could, however, do something similar to the DOCTYPE
switching in browsers. If a page is old-style tag soup, it's very likely
not to be following the HTML spec, so process it by trying to divine
meaning and context through heuristics etc. If a DOCTYPE is present,
give preference to using HTML's features that can unequivocally define
meaning and context, rather than guesstimating.

> What a great vision it would be if all of a sudden browsers refused to
> display invalid markup

I've often pondered what it would be like if widely used browsers such
as IE had a (subtle, but still quite visible) warning sign for tag soup
sites (similar to the warning triangle you get for javascript errors,
but a bit more visible and obvious). I could imagine discussions between
web developers and their bosses (head of marketing or similar) along the
lines of "why does our site bring up that warning, while our
competitor's site doesn't?" (this obviously focussed on developers who
don't care about standards and work in a corporate environment).

P
--
Patrick H. Lauke
___________
re

From: Jukka K. Korpela
Date: Fri, Mar 24 2006 11:50AM
Subject: Re: FW: HTML - <abbr> and <acronym> settings
← Previous message | No next message

On Fri, 24 Mar 2006, Patrick H. Lauke wrote:

> Assistive technology could, however, do something similar to the DOCTYPE
> switching in browsers.

What a frightening idea.

> If a DOCTYPE is present, give preference to
> using HTML's features that can unequivocally define meaning and context,
> rather than guesstimating.

By definition, a DOCTYPE declaration specifies the formal syntax rules
that a document purports to comply with. Nothing more, nothing less. Any
conclusions concerning semantics add just wild guesses to the current
guesswork and are bound to give wrong results _very_ often.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/