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.
Here are the aural properties I need to get via getComputedStyle: (from http://www.w3.org/TR/REC-CSS2/aural.html) 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. Reassigning.
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 pretty easy... 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 http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Changing from topembed, to embed, as this is not blocking a major embedding customer.
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. <http://www.w3.org/TR/css3-speech/>
*** 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: http://clc4tts.clcworld.net/css_technical.html
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? Sebastian
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...