Addressbook new field proposal
Ron K.
We can assist ourselves to improve our accessibility support. Into the
Abook UI I propose adding a checkbox for "Recipient is Blind". Given
the broken state of composer as a CSS supporting editor, We are unable
to generate a valid {style: type=audio } style sheet to meet the goals
of the W3C.
So as an intermediate measure, I see the new UI invoking an HTML compose
preference override on a Address Card basis. This should bypass the text
to speech difficulties that can arise, example Alt="" null content.
If any one thinks this proposal is insulting as stated, it can be
implemented in an inverted way, "Recipient prefers Visual styling only".
So a missing checkoff reverts to text/plain *No CSS* message. We have an
existing HTML checkoff that this proposal would extend to toggle the
added CSS. This proposal is targeted at support from a future Composer
capable of sending both Screen and Audio style sheets in a messages Head
/Head as the final goal of reaching the W3C standards for accessibility.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
Joshua Cranmer
> After I commented in the thread "Perceptions and usability" I realized
> We can assist ourselves to improve our accessibility support. Into the
> Abook UI I propose adding a checkbox for "Recipient is Blind". Given
> the broken state of composer as a CSS supporting editor, We are unable
> to generate a valid {style: type=audio } style sheet to meet the goals
> of the W3C.
One word of warning: currently, aural style sheets are not
well-supported. The section was defined as non-normative in CSS 2.1 (due
to lack of implementation); CSS 3 Speech was recently classified as "low
priority," and is one of the modules most at risk of dieing. AFAIK, no
popular screen reader supports it; the only browser (much less email
client) that supports it is Opera, and even then it's only experimental.
> So as an intermediate measure, I see the new UI invoking an HTML compose
> preference override on a Address Card basis. This should bypass the text
> to speech difficulties that can arise, example Alt="" null content.
While I don't mean to belittle accessibility concerns, I fail to see how
much help this would provide. Citing the images, images in email would
tend to fall into two categories: pictures of some event, which I doubt
blind people would be receiving on a regular basis, or small pictures
(e.g. bullets) that would not have proper alt-text anyways.
Even more important would be the question as to why we would need an
option in the first place. Accessibility shouldn't impact the final
result for those who do not need it; why should we have an option then
to cripple accessibility?
> If any one thinks this proposal is insulting as stated, it can be
> implemented in an inverted way, "Recipient prefers Visual styling only".
> So a missing checkoff reverts to text/plain *No CSS* message. We have an
> existing HTML checkoff that this proposal would extend to toggle the
> added CSS. This proposal is targeted at support from a future Composer
> capable of sending both Screen and Audio style sheets in a messages Head
> /Head as the final goal of reaching the W3C standards for accessibility.
I'd say it's probably better just to get Composer accessible rather than
trying to muck about creating thorny UI issues to give the user a choice
as to whether or not to include accessibility.
Robert Kaiser
> Given the
> broken state of composer as a CSS supporting editor, We are unable to
> generate a valid {style: type=audio } style sheet to meet the goals of
> the W3C.
AFAIK, aural style is not needed for making good accessible mail, and
actually, most of what Composer generates is quite usable for visually
impaired people, our UI has larger problems there, most/all of which can
be fixed with adding XUL attributes.
That said, Marco can comment on this much better than most of us
well-sighted non-accessibility-experts.
Robert Kaiser
Ron K.
> Ron K. wrote:
>> After I commented in the thread "Perceptions and usability" I
>> realized We can assist ourselves to improve our accessibility
>> support. Into the Abook UI I propose adding a checkbox for "Recipient
>> is Blind". Given the broken state of composer as a CSS supporting
>> editor, We are unable to generate a valid {style: type=audio } style
>> sheet to meet the goals of the W3C.
>
> One word of warning: currently, aural style sheets are not
> well-supported. The section was defined as non-normative in CSS 2.1
> (due to lack of implementation); CSS 3 Speech was recently classified
> as "low priority," and is one of the modules most at risk of dieing.
> AFAIK, no popular screen reader supports it; the only browser (much
> less email client) that supports it is Opera, and even then it's only
> experimental.
This is information I was not up on. I did not want to opening a bad RFE
that would have to die during a Bugday.
>> So as an intermediate measure, I see the new UI invoking an HTML
>> compose preference override on a Address Card basis. This should
>> bypass the text to speech difficulties that can arise, example Alt=""
>> null content.
>
> While I don't mean to belittle accessibility concerns, I fail to see
> how much help this would provide. Citing the images, images in email
> would tend to fall into two categories: pictures of some event, which
> I doubt blind people would be receiving on a regular basis, or small
> pictures (e.g. bullets) that would not have proper alt-text anyways.
>
> Even more important would be the question as to why we would need an
> option in the first place. Accessibility shouldn't impact the final
> result for those who do not need it; why should we have an option then
> to cripple accessibility?
I was thinking about unnecessary baggage if an aural style sheet was not
needed by a recipient, yet assure one was inserted when useful.
>> If any one thinks this proposal is insulting as stated, it can be
>> implemented in an inverted way, "Recipient prefers Visual styling
>> only". So a missing checkoff reverts to text/plain *No CSS* message.
>> We have an existing HTML checkoff that this proposal would extend to
>> toggle the added CSS. This proposal is targeted at support from a
>> future Composer capable of sending both Screen and Audio style sheets
>> in a messages Head /Head as the final goal of reaching the W3C
>> standards for accessibility.
>
> I'd say it's probably better just to get Composer accessible rather
> than trying to muck about creating thorny UI issues to give the user a
> choice as to whether or not to include accessibility.
Given the possability of W3C dropping aural style sheets from CSS3, then
I would rather see resources invested in Composer gaining easier User
selection of CSS from UI rather than from User memory.
Thank you for the feedback.
JoeS
> After I commented in the thread "Perceptions and usability" I realized
> We can assist ourselves to improve our accessibility support. Into the
> Abook UI I propose adding a checkbox for "Recipient is Blind". Given the
> broken state of composer as a CSS supporting editor, We are unable to
> generate a valid {style: type=audio } style sheet to meet the goals of
> the W3C.
>
> So as an intermediate measure, I see the new UI invoking an HTML compose
> preference override on a Address Card basis. This should bypass the text
> to speech difficulties that can arise, example Alt="" null content.
>
> If any one thinks this proposal is insulting as stated, it can be
> implemented in an inverted way, "Recipient prefers Visual styling only".
> So a missing checkoff reverts to text/plain *No CSS* message. We have an
> existing HTML checkoff that this proposal would extend to toggle the
> added CSS. This proposal is targeted at support from a future Composer
> capable of sending both Screen and Audio style sheets in a messages Head
> /Head as the final goal of reaching the W3C standards for accessibility.
>
I'm sure you know that templates can be constructed with styesheets (not in head except w/EditHtml extension)
The use of templates has not been emphasized enough, one thing that would be helpful is a "reply with template"
function. The saved template including the desired accessability enhancements could be inserted in the reply easily.
Of course you would have to resolve the problem of multiple mail styles over-riding each other, but I'm sure we
could come up with some scheme to do this.
Marco Zehe
Robert Kaiser wrote:
> AFAIK, aural style is not needed for making good accessible mail, and
> actually, most of what Composer generates is quite usable for visually
> impaired people, our UI has larger problems there, most/all of which can
> be fixed with adding XUL attributes.
Correct! The HTML generateed by Compose is rather accessible in fact!
And both you and Joshua are correct in your assessment regarding
stylesheets of type aural. This has mostly been dropped in favour of
making websites accessible in a way that benefits all and which saves
double work.
> That said, Marco can comment on this much better than most of us
> well-sighted non-accessibility-experts.
:-) Well, you know my opinion on the HTML versus Plain Text indicator.
Marco
Prasad Sunkari
> After I commented in the thread "Perceptions and usability" I realized
> We can assist ourselves to improve our accessibility support. Into the
> Abook UI I propose adding a checkbox for "Recipient is Blind". Given the
> broken state of composer as a CSS supporting editor, We are unable to
> generate a valid {style: type=audio } style sheet to meet the goals of
> the W3C.
>
I somehow would take a completely different stand on the accessibility
for the visually impaired issue. Some points to note are:
1. Being visually impaired does not just mean being blind. It could
even be color blindness where the person fails to distinguish between
low contrast colors.
2. There are many existing solutions which make the systems accessible
to the visually impaired, like high-contrast themes, Braille terminals
and Screen Readers, which are generally supported through the platforms
accessibility layers.
What I would expect an email software to do on the senders side is to
put information as plainly as possible and not try to block what can be
made accessible.
On the recipients side, the software should properly implement support
to the accessibility frameworks and should be able to use the platform's
theme. Both these issues are currently pretty well addressed with
Thunderbird (Mozilla Toolkit) and few other email software. This
probably is the direction Thunderbird should go so that the
accessibility is ensured irrespective of the disability and irrespective
of the solution the impaired person prefers (Eg: Screen Readers vs
Braille Terminal)
The existing screen reader based technology can already let the visually
impaired person quote and reply to a mail.
Well, all that said, IMHO a new field need not be added to the addressbook.
Prasad
Ron K.
I was not up to speed on is how current code supports existing
technology solutions. In this discussion I took a future view of the
case where CSS specs for aural CSS would be implemented. Since this is
nowhere close to being realized the idea is irrelevant.