Rapid development leads to many incompatible AddOns

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Rapid development leads to many incompatible AddOns

McGyver008
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Rapid development leads to many incompatible AddOns

Jamal Mazrui-2
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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Rapid development leads to many incompatible AddOns

Alexander Surkov
In reply to this post by McGyver008
On Oct 8, 8:59 pm, McGyver008 <[hidden email]> 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...?

Hi, your concern is more general than disability access support and
persons who's able to discuss the topic don't watch this list. Please
file it to more generic list.

Alexander.
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Rapid development leads to many incompatible AddOns

Alexander Surkov
In reply to this post by McGyver008
On Oct 8, 10:20 pm, Jamal Mazrui <[hidden email]> 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
> > [hidden email]
> >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.
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

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

Jamal Mazrui-2
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 <[hidden email]>
>> Organization: http://groups.google.com
>> Newsgroups: mozilla.dev.accessibility
>> References:
>> <[hidden email]>
>> <[hidden email]>
>>
>> On Oct 8, 10:20 pm, Jamal Mazrui <[hidden email]> 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
>>> > [hidden email]
>>> >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.
>>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

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

Marco Zehe-3
In reply to this post by Alexander Surkov
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 <[hidden email]>
>>> Organization: http://groups.google.com
>>> Newsgroups: mozilla.dev.accessibility
>>> References:
>>> <[hidden email]>
>>> <[hidden email]>
>>>
>>> On Oct 8, 10:20 pm, Jamal Mazrui <[hidden email]> 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
>>>> > [hidden email]
>>>> >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.
>>>

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility