|
squiggly markers for errors in Eclipse - anyway to replace them?
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hello Everyone,
If one gets an error when typing inside of Eclipse
you see a squiggly line
near the error. However, for a screen reader
it will not designate such an
error.
Is there a way or a plugin to
get a popup window or a sound alert if an
error takes place that anyone is
aware of?
Jeff
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA-ACCESS". For general help, send email to
listserv@... and include in the body of the message "help".
|
|
Re: squiggly markers for errors in Eclipse - anyway to replace them?
If one gets an error when typing inside of Eclipse you
see a squiggly line
near the error. However, for a screen reader it will not designate
such an
error.
Isn't that really an opportunity for
writing a script? Doesn't JAWS & WindowEyes see the squiggly
line character - if so, then it is the AT that needs to be customized to
react to it correctly - just as it has been done for Microsoft Word or
any other application that uses special characters to identify misspellings,
etc.
Regards,
Phill Jenkins
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA-ACCESS". For general help, send email to
listserv@... and include in the body of the message "help".
|
|
Re: squiggly markers for errors in Eclipse - anyway to replace them?
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I believe in the case of Word this information is
obtained via the object model of that application. Do you know if a COM
interface exists within Eclipse to gain access to that information?
Jeff
----- Original Message -----
Sent: Monday, July 14, 2008 9:06 AM
Subject: Re: squiggly markers for errors
in Eclipse - anyway to replace them?
If one gets an error when typing inside of
Eclipse you see a squiggly line
near the error. However, for a
screen reader it will not designate such an
error.
Isn't that really an opportunity for writing a script?
Doesn't JAWS & WindowEyes see the squiggly line character - if so,
then it is the AT that needs to be customized to react to it correctly - just
as it has been done for Microsoft Word or any other application that uses
special characters to identify misspellings, etc.
Regards,
Phill Jenkins
IBM Research - Human
Ability & Accessibility Center
http://www.ibm.com/able
=========================================================================== To
unsubscribe, send email to listserv@... and include in the body of
the message "signoff JAVA-ACCESS". For general help, send email to
listserv@... and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA-ACCESS". For general help, send email to
listserv@... and include in the body of the message "help".
|
|
Re: squiggly markers for errors in Eclipse - anyway to replace them?
Dear Phill,
I think the first question to ask is *how* does an AT like JAWS
determine that a portion of text has a a squiggly line underneath it
(or any other attribute/styling). I believe JAWS & WindowEyes do
this with Microsoft Word by using the proprietary COM APIs that Word
exposes - essentially by "going to the DOM" to determine this.
In applications using a uniform accessibility API (e.g. iAccessible2)
and not providing a unique-to-them DOM/COM interface, the question
becomes "how should one expose this information via iAccessible2" (or
whatever is the appropriate accessibility API in question). A first
choice might be via text attributes, though this can be challenging to
implement because the information is typically stored and even
sometimes rendered in a very different part of the application from the
part that knows about boldface/underlining, etc.
Apropos of this, a very similar issue is being worked on right now in
the Linux Foundation's Open Accessibility working group, where IBM's
Pete Brunet is working through a proposal conveying change tracking
information via iAccessible2 and the UNIX ATK/AT-SPI interfaces.
So I think the actual answer is: JAWS isn't given enough information
today to do this in Eclipse, but hopefully in not too long the
accessibility APIs will be exposed to allow JAWS (or someone writing a
script for JAWS) to do so.
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
If one gets an error when typing inside of Eclipse you
see a squiggly line
near the error. However, for a screen reader it will not designate
such an
error.
Isn't that really an opportunity for
writing a script? Doesn't JAWS & WindowEyes see the squiggly
line character - if so, then it is the AT that needs to be customized
to
react to it correctly - just as it has been done for Microsoft Word or
any other application that uses special characters to identify
misspellings,
etc.
Regards,
Phill Jenkins
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
===========================================================================
To unsubscribe, send email to listserv@... and include in the
body
of the message "signoff JAVA-ACCESS". For general help, send email to
listserv@... and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA-ACCESS". For general help, send email to
listserv@... and include in the body of the message "help".
|
|
Re: squiggly markers for errors in Eclipse - anyway to replace them?
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Peter,
Do you know if Eclipse has a com way of getting at
that information?
Jeff
----- Original Message -----
Sent: Monday, July 14, 2008 9:55 AM
Subject: Re: squiggly markers for errors
in Eclipse - anyway to replace them?
Dear Phill,
I think the first question to ask is *how*
does an AT like JAWS determine that a portion of text has a a squiggly line
underneath it (or any other attribute/styling). I believe JAWS &
WindowEyes do this with Microsoft Word by using the proprietary COM APIs that
Word exposes - essentially by "going to the DOM" to determine this.
In applications using a uniform accessibility API (e.g. iAccessible2)
and not providing a unique-to-them DOM/COM interface, the question becomes
"how should one expose this information via iAccessible2" (or whatever is the
appropriate accessibility API in question). A first choice might be via
text attributes, though this can be challenging to implement because the
information is typically stored and even sometimes rendered in a very
different part of the application from the part that knows about
boldface/underlining, etc.
Apropos of this, a very similar issue is
being worked on right now in the Linux Foundation's Open Accessibility working
group, where IBM's Pete Brunet is working through a proposal conveying change
tracking information via iAccessible2 and the UNIX ATK/AT-SPI
interfaces.
So I think the actual answer is: JAWS isn't
given enough information today to do this in Eclipse, but hopefully in not too
long the accessibility APIs will be exposed to allow JAWS (or someone writing
a script for JAWS) to do so.
Regards,
Peter
Korn
Accessibility Architect,
Sun Microsystems, Inc.
If one gets an error when typing inside of
Eclipse you see a squiggly line
near the error. However, for a
screen reader it will not designate such an
error.
Isn't that really an opportunity for writing a
script? Doesn't JAWS & WindowEyes see the squiggly line character
- if so, then it is the AT that needs to be customized to react to it
correctly - just as it has been done for Microsoft Word or any other
application that uses special characters to identify misspellings,
etc.
Regards,
Phill
Jenkins
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
===========================================================================
To unsubscribe, send email to listserv@... and include in
the body of the message "signoff JAVA-ACCESS". For general help, send email
to listserv@... and include in
the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@... and include in the body of
the message "signoff JAVA-ACCESS". For general help, send email to
listserv@... and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA-ACCESS". For general help, send email to
listserv@... and include in the body of the message "help".
|
|
Re: squiggly markers for errors in Eclipse - anyway to replace them?
Jeff, We've been discussing this matter
(along with grammar errors) in the IAccessible2 group for some time now
and the discussion is at a point where I'm waiting for some input from
the OpenOffice team. In Lotus Symphony the red wavy underlines are
exposed using IA2's IAccessibleText::attributes indicating that there is
an underline, that it is wavy, and that it is red. However, what
is really needed is to expose that there is an error of a certain sort,
e.g. spelling or grammar, not that there is an underline with particular
attributes. There are two ways to expose the error, either as a text
attribute, e.g. ...;spelling-error:true;grammar-error:true;... or an interface
(or a pair of interfaces) that returns the error information. If
you have any input regarding this issue the IA2 site is at http://www.linuxfoundation.org/en/Accessibility/IAccessible2
and the mailing list info is at https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2.
Thanks,
Pete Brunet
IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 838-4594, Cell: (512) 689-4155
Ionosphere: WS4G
Peter,
Do you know if Eclipse has a com way of getting
at that information?
Jeff
----- Original Message -----
From: Peter
Korn
To: JAVA-ACCESS@...
Sent: Monday, July 14, 2008 9:55 AM
Subject: Re: squiggly markers for errors in Eclipse
- anyway to replace them?
Dear Phill,
I think the first question to ask is *how* does an AT like JAWS determine
that a portion of text has a a squiggly line underneath it (or any other
attribute/styling). I believe JAWS & WindowEyes do this with
Microsoft Word by using the proprietary COM APIs that Word exposes - essentially
by "going to the DOM" to determine this.
In applications using a uniform accessibility API (e.g. iAccessible2) and
not providing a unique-to-them DOM/COM interface, the question becomes
"how should one expose this information via iAccessible2" (or
whatever is the appropriate accessibility API in question). A first
choice might be via text attributes, though this can be challenging to
implement because the information is typically stored and even sometimes
rendered in a very different part of the application from the part that
knows about boldface/underlining, etc.
Apropos of this, a very similar issue is being worked on right now in the
Linux Foundation's Open Accessibility working group, where IBM's Pete Brunet
is working through a proposal conveying change tracking information via
iAccessible2 and the UNIX ATK/AT-SPI interfaces.
So I think the actual answer is: JAWS isn't given enough information today
to do this in Eclipse, but hopefully in not too long the accessibility
APIs will be exposed to allow JAWS (or someone writing a script for JAWS)
to do so.
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
If one gets an error when typing inside of Eclipse you see a squiggly line
near the error. However, for a screen reader it will not designate
such an
error.
Isn't that really an opportunity for writing a script? Doesn't JAWS
& WindowEyes see the squiggly line character - if so, then it is the
AT that needs to be customized to react to it correctly - just as it has
been done for Microsoft Word or any other application that uses special
characters to identify misspellings, etc.
Regards,
Phill Jenkins
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
===========================================================================
To unsubscribe, send email to listserv@...
and include in the body of the message "signoff JAVA-ACCESS".
For general help, send email to listserv@...
and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@... and include in the
body of the message "signoff JAVA-ACCESS". For general help,
send email to listserv@... and include in the body of the message
"help".
===========================================================================
To unsubscribe, send email to listserv@... and include in the
body of the message "signoff JAVA-ACCESS". For general help,
send email to listserv@... and include in the body of the message
"help".
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA-ACCESS". For general help, send email to
listserv@... and include in the body of the message "help".
|
|
Re: squiggly markers for errors in Eclipse - anyway to replace them?
A few comments:
1. Text attributes - knowing the text
attributes is (should be) independent of the semantics that an error is
also being represented. The fundamental principle that presentation
should be separated from semantics comes into play here. Some may
prefer and/or need it presented as a yellow box, or larger font with different
contrast, or the red squiggly line - but the user/AT/agent still needs
to know the semantics - spelling, grammatical, syntax, or what-ever error.
2. Extensible error type: It would
be useful for the error types to be extendable. Start off with the
common ones today, such as spelling, grammar, syntax,etc. But allow the
API to be extended to include additional ones yet to be defined.
3. API - Isn't API the preferred method
over querying every character and storing information about the text attributes
and/or error types? It is usually a big performance hit to the AT
to have to query every text and store it attributes and error types. Much
more efficient to allow the AT to query the DOM via an API on demand and
get the strings of errors.
Regards,
Phill Jenkins
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA-ACCESS". For general help, send email to
listserv@... and include in the body of the message "help".
|
|
Re: squiggly markers for errors in Eclipse - anyway to replace them?
Hi Phill,
A few comments:
...
3. API - Isn't API the preferred
method
over querying every character and storing information about the text
attributes
and/or error types? It is usually a big performance hit to the AT
to have to query every text and store it attributes and error types.
Much
more efficient to allow the AT to query the DOM via an API on demand
and
get the strings of errors.
This is precisely what the new collections interface is about -
allowing an AT to make queries and get back a list of the
objects/places that meet the query (the collection of things meeting
the query if you will). This kind of approach is much more generic
than application-specific DOMs, and much easier to implement broadly
than trying to generify a DOM across a spectrum of very different
applications (a word processed document DOM likely looks quite
different from a spreadsheet DOM, and those different from a vector
graphics editor DOM).
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA-ACCESS". For general help, send email to
listserv@... and include in the body of the message "help".
|
|
Re: squiggly markers for errors in Eclipse - anyway to replace them?
There are two proposals being discussed
by the IA2 WG.
1) use new text attributes like spelling-error;grammar-error;
or
2) use interfaces/methods to determine
if there is an error and if so what kind of error it is.
I'm hoping to get to a consensus on
this soon.
BTW, IA2 doesn't have a Collection interface.
It was added to ATK/AT-SPI because of its cross process architecture.
The Collection interface can be used to cut down on the cross
process calls. IA2 ATs tend to be in process, though now we also
have NVDA which is mostly out of process due being written in Python.
Pete Brunet
IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 838-4594, Cell: (512) 689-4155
Ionosphere: WS4G
Hi Phill,
A few comments:
...
3. API - Isn't API the preferred method over querying every character and
storing information about the text attributes and/or error types? It
is usually a big performance hit to the AT to have to query every text
and store it attributes and error types. Much more efficient to allow
the AT to query the DOM via an API on demand and get the strings of errors.
This is precisely what the new collections interface is about - allowing
an AT to make queries and get back a list of the objects/places that meet
the query (the collection of things meeting the query if you will). This
kind of approach is much more generic than application-specific DOMs, and
much easier to implement broadly than trying to generify a DOM across a
spectrum of very different applications (a word processed document DOM
likely looks quite different from a spreadsheet DOM, and those different
from a vector graphics editor DOM).
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
===========================================================================
To unsubscribe, send email to listserv@... and include in the
body of the message "signoff JAVA-ACCESS". For general help,
send email to listserv@... and include in the body of the message
"help".
===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVA-ACCESS". For general help, send email to
listserv@... and include in the body of the message "help".
|
