Re: Fwd: Re: Rapid development leads to many incompatible AddOns

Jamal,

the problem you're describing sounds very much like this: Since Firefox 
4 and Thunderbird built from the same platform version, it is absolutely 
necessary that the screen reader be started *before* Firefox or 
Thunderbird, or otherwise some hooks will be missing to allow the screen 
reader to determine just when to turn on virtual buffers.

Moreover, there is a difference between NVDA and some others on the one 
side, and JAWS, Window-Eyes and some others on the other. If you have 
NVDA running and start Firefox, then quit NVDA and start JAWS, Firefox 
will not have the correct hooks in place to support JAWS. Esp JAWS 12 
and older versions are affected, JAWS 13 addresses this technical quirk 
on their end, as you noted.

So if you had NVDA running, started Firefox, then need to look at 
something with JAWS or Window-Eyes, quit Firefox, quit NVDA, start JaWS 
or WE, start Firefox. That's the order you must uphold or you will get 
some difficulties.

Marco

Am 08.11.2011 12:56, schrieb Jamal Mazrui:
> Correction: I meant "top posting" rather than "top quoting."
>
> To elaborate a bit, the incompatibility problems often seem to be
> related to determining whether the screen reader correctly detects that
> Thunderbird or Firefox is displaying HTML content. If so, screen readers
> typically turn on a browse or virtual mode automatically, which includes
> many single-letter hotkeys for navigating among HTML elements. It is
> generally much less efficient to read HTML content without that special
> mode.
>
> Another common area of problems is the TB composition Window. I think TB
> is supposed to use iAccessible2 for full editing support via a screen
> reader, but for some reason, screen readers are not harmonizing with
> that iA2 interface, thus often making it difficult to edit the text of a
> message accurately.
>
> Jamal
>
>
> On 11/8/2011 6:46 AM, Jamal Mazrui wrote:
>> Sorry for not responding sooner -- I did not find the reply text before.
>> I know that in-line quoting is favored by sighted technical people, but
>> unfortunately, top quoting tends to be considerably more accessible to
>> screen reader users.
>>
>> I have noticed support for Thundirbird and Firefox broken in JAWS, NVDA,
>> and Window-Eyes due to major version changes over the past year. It is
>> so bad that users often encourage newcomers to stay with TB 3.1 for now.
>> As a specific, JAWS 12 stopped being able to read a message
>> automatically when it was opened in TB 5 and above (this has since been
>> fixed in JAWS 13). As a developer of JAWS scripts for TB, I found that
>> less information was available via MSAA in TB 5 and above than before.
>>
>> Unfortunately, these observations and experiences make me seriously
>> question Mozilla's testing process with screen readers.
>>
>>
>> Jamal
>>
>> On 11/6/2011 8:40 AM, Wayne Mery (vn) wrote:
>>> jamal ??
>>>
>>> -------- Original Message --------
>>> Subject: Re: Rapid development leads to many incompatible AddOns
>>> Date: Mon, 10 Oct 2011 18:15:23 -0700 (PDT)
>>> From: Alexander Surkov <[email protected]>
>>> Organization: http://groups.google.com
>>> Newsgroups: mozilla.dev.accessibility
>>> References:
>>> <316673de-9368-4f84-88e8-8732343ceb9b@d18g2000yql.googlegroups.com>
>>> <mailman.12926.1318080034.4544.dev-accessibility@lists.mozilla.org>
>>>
>>> On Oct 8, 10:20 pm, Jamal Mazrui <[email protected]> wrote:
>>>> I agree that the major version changes have been coming too quickly
>>>> with
>>>> Firefox and Thunderbird. Among other things, the changes have been
>>>> breaking accessibility with screen readers.
>>>>
>>>> Jamal
>>>>
>>>> On 10/8/2011 7:59 AM, McGyver008 wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> > Hi to all,
>>>>
>>>> > directly spoken: One of the most interesting features of FF - the
>>>> > AddOn's - get more and more often problems because of the
>>>> method(s) of
>>>> > FF's development.
>>>>
>>>> > Although development in general is necessary, of course and very
>>>> > important.. but I don't understand, why some basic functionality (for
>>>> > example some interface modules als well as JavaScript, I assume)
>>>> > changes that quickly.
>>>>
>>>> > Many AddOn's need significantly more time for updates and in the
>>>> > moment even some well-known AddOn's like DownThemAll do only support
>>>> > FF 6.X, although there are 4 (!) complete new 'levels' of FF versions
>>>> > in nightly available (7.x, 8.x, 9.x, 10.x). Even the releases
>>>> begin to
>>>> > outspace some AddOn's.
>>>>
>>>> > Ok, my question: Why is it necessary to change so many aspects in a
>>>> > way, that make make it essential to rewrite so many AddOn's with
>>>> every
>>>> > new 'major version step' (e.g. 6.x to 7.x)? I don't understand,
>>>> why it
>>>> > is so important to make several steps during one year (it is really
>>>> > very strange - sorry - to see FF versions ranging between 3.x and
>>>> 10.x
>>>> > in use... even though some of them are only nightly's and some others
>>>> > are known to be outdated... it looks like an inflation in versions).
>>>> > Well done software need to be updated as well, but not permanently
>>>> > from ground up - sorry. It looks like there is a preference in
>>>> > development... and speed in development seems to beat quality
>>>> > completely. Can this really be a good idea...?
>>>> > _______________________________________________
>>>> > dev-accessibility mailing list
>>>> > [email protected]
>>>> >https://lists.mozilla.org/listinfo/dev-accessibility
>>>
>>> Hi, Jamal. What kind of problems of screen readers support can you see
>>> because of rapid release cycle?
>>> Alexander.
>>>