Mozilla should have an option to voice read the web pages. CSS 2 has implemented
voice options. The voice-browsers standarts can be finded on W3C homepage.
Suggest marking a duplicate of Bug #12952 since they're both up the same street.
*** This bug has been marked as a duplicate of 12952 ***
verified dupe of bug 12952 -On the Windows platform, the browser does not expose
its UI and contents to
Microsoft Active Accessibility. This means that a plethora of accessibility
aids (screen readers, magnifiers, etc.) will not work with Mozilla!
This should not be a duplicate of 12952. Support for CSS 2 audio & braille
isn't the same as supporting MSAA. Blazie Engineering will help implement
support for CSS 2. Contact email@example.com for details.
over to Style system. aaron, is this a bug that you would like to own?
Asa, I don't want to own it, but I will ask my co-worker to own it within the
next couple of months. We will talk about it more during my December visit.
I think that the Aural properties are already parsed correctly but there is still
a little bit of work to do to store them in the StyleContext.
It's not really a Style problem. Most of the work has to be done in XPToolkit as
described in bug 12952.
I've already got Mozilla speaking
I just need to know how to get to the aural and braille css properties from C++
What do you mean about getting them stored in the style context? How do I do
that/ who can do that for me?
Here are the aural properties I need to get via getComputedStyle:
volume, speak, pause-before, pause-after, pause, cue-before, cue-after, cue,
play-during, azimuth, elevation, speech-rate, voice-family, pitch, pitch-range,
stress, richness, speak-punctuation, speak-numeral.
Also, there are @media types I'm interested, such as braille and embossed. How
do I use one of those in getComputedStyle?
Aarlon: See http://www.w3.org/TR/DOM-Level-2-Style
Netscape's standard compliance QA team reorganised itself once again, so taking
remaining non-tables style bugs. Sorry about the spam. I tried to get this done
directly at the database level, but apparently that is "not easy because of the
shadow db", "plus it screws up the audit trail", so no can do...
jst: Should this go to Harish?
Indeed it should.
Aaron, when is this needed, the getComputedStyle() code is now in pretty good
shape (thanks to Harish) so adding support for this should be really easy. Let
us know how soon you need this.
I just spoke to Harish about this bug. There is a fair amount of work to do in
the style system first: creating an Aural struct in the StyleContext, cascading
the aural properties, and mostly, testing that the value constraints,
inheritance and default values are all correct. I estimate this to be about a
week total, with 3 days for implementation and 2 for testing. Fortunately, we
have some excellent QA resources to help with the testing :)
Once the aural properties are in the style context, Harish's part should be
CC'ing marek on this one for some help in prioritization. Pierre could certainly
do the style work as well as or better than I, but he is going on sabbatical
Real soon Now and may not be able to attend to this before leaving.
Please don't work in the implementation in nsStyleContext.cpp in the next 2
weeks. If I manage to check in my changes for bug 43457 before I leave, it will
be much easier to support the aural properties.
last I checked, we _do_ support them and cascade them. For every single element
in the entire DOM. In fact some people have suggested we might want to save
some memory and speed by cheating and disabling them. (Not that I approve, IMHO
since they are not used by most people, the properties shouldn't be taking any
time or space at all, unless someone uses them.)
These properties are parsed and there might be a minimum level of DOM support
because they appear in the CSS declarations, but we certainly don't cascade them.
They are not stored in the style context and the nsComputedDOMStyle functions for
aural properties all return a 'non-supported' error.
Reassigned to myself but if I don't fix it before my sabbatical, please feel free
to take it back.
Not sure if you noticed, Pierre, but this is on the Hot List
(http://bugzilla.mozilla.org/show_bug.cgi?id=75664) for Moz 0.9.
Moving to m0.9.
Set to P1/critical instead of P3/enhancement because it is on the Hot List.
figured out that 0.9 should be ok.
0.9.1 that is. This bug is not actually on Marek's hot list, it was added as a
dependency of a tracking bug that is on Marek's list, by a mozilla contributor,
without any comment as to why it was added. Thus, we have no indication so far
that this is needed for MSAA support.
Pierre: I stand corrected.
If it's not on the HotList, I can mark it Future and dependent on bug 43457...
Shouldn't this also have keyword DOM2 attached (since it is one of the 2
remaining bugs blocking Bug 42417)?
Assigning pierre's remaining Style System-related bugs to myself.
batch: adding topembed per Gecko2 document
Changing from topembed, to embed, as this is not blocking a major embedding
FWIW, all aural stuff will most likely be heavily reworked in CSS3.
Bulk adding topembed keyword. Gecko/embedding needed.
Is still needed? (Note that CSS 2.1 deprecates the media "aural" and "suggests"
using "speech" instead.)
(In reply to comment #30)
> FWIW, all aural stuff will most likely be heavily reworked in CSS3.
Is CSS 3 still happening? I hear CSS work has ended.
Anyway, we will need this eventually, whether it's called speech or aural.
> Is CSS 3 still happening? I hear CSS work has ended.
*** Bug 317340 has been marked as a duplicate of this bug. ***
Status ping. Does anyone have implementing css3-speech on their TODO horizon?
I don't think so, but if I were aware that somebody had plans to use it, that might change.
The maker of the free screen reader Fire Vox would benefit greatly from having this bug fixed. See "Limitations of Firefox" here:
This issue was opened in 2000. Looking at http://css3test.com it still isn't fixed in FF 29.
To make progress on this issue wouldn't it help to split it into smaller tasks? I.e. create an issue for each property?
So a new issue for each of these:
7.1. The ‘voice-volume’ property
7.2. The ‘voice-balance’ property
8.1. The ‘speak’ property
8.2. The ‘speak-as’ property
9.1. The ‘pause-before’ and ‘pause-after’ properties
9.2. The ‘pause’ shorthand property
9.3. Collapsing pauses
10.1. The ‘rest-before’ and ‘rest-after’ properties
10.2. The ‘rest’ shorthand property
11.1. The ‘cue-before’ and ‘cue-after’ properties
11.2. Relation between audio cues and speech synthesis volume levels
11.3. The ‘cue’ shorthand property
12.1. The ‘voice-family’ property
12.2. The ‘voice-rate’ property
12.3. The ‘voice-pitch’ property
12.4. The ‘voice-range’ property
12.5. The ‘voice-stress’ property
13.1. The ‘voice-duration’ property
Also important to think of how this will be used by assistive technology too http://community.nvda-project.org/ticket/4242
Update: please use the editor's draft https://drafts.csswg.org/css-speech/ as it has substantial updates since the last public draft http://www.w3.org/TR/css3-speech/
Also the CSS WG resolved today to publish a new CR of CSS Speech, so that Editor's draft will likely shortly get snapshotted and published in TR: https://www.w3.org/2017/02/15-css-irc#T17-39-53
Since this bug is about getComputedStyle in particular, creating meta bug for the module accordingly now...