Actually, java swing has a built-in mechanism for associating labels with controls. on the JLabel object is a method called something like setAsLabelFor which takes another component like a text field as an arguement. In the accessibility framework, this associates the label with the control. The accessibility framework also contains other features for attempting to simplify the labeling of controls such as using the tool tip text if no value is found for the accessibleDescription property. So, as you can see, the accessibility framework within java is extremely powerful. It is just coming up with the best solution for exposing all this wonderful data to the outside world which is a challenge. This is where I hope our accessibility project can show some real progress.
----- Original Message ----- From: "Roopakshi Pathania" <r_akshi_tgk@xxxxxxxxx>
To: <programmingblind@xxxxxxxxxxxxx> Sent: Thursday, June 17, 2010 12:06 PM Subject: RE: Developing cross-platform, accessible apps Hi,Not that my knowledge is really extensive, I’m not a hardcore programmer, more like a tinkerer.
But there are 2 aspects to automatically labeling a control.Any platform that insists on labeling a control automatically using some kind of a constructor reduces the flexibility available to the developers. The method invoked to auto-label your single edit line field would require the label to be placed at a fixed position, have a maximum length, or even require a set distance between the label and the control. Only Apple has that kind of clout to dictate terms to the developers. <smile>
The next situation could be where the developer decides to create a custom object to make her task easier and less repetitive. In this case, code can be written to add an edit box and its label, and then to call the setLabelFor method of the label. Such a control would need methods for setting label size, label position relative to edit box, size of edit box, etc. In this kind of a custom control, you would need to take account of so many things, size of label (may try and do it automatically for the text in the label but it probably would need to allow the developer to manually set the label size), size of control, etc. However some things may be able to be reduced out as you probably have a standard for the
application (e.g. you probably will always have labels on one side of thecheckboxes, you probably have a set spacing you want the label from the control, etc).
Regards Roopakshi --- On Wed, 6/16/10, Homme, James <james.homme@xxxxxxxxxxxx> wrote:
From: Homme, James <james.homme@xxxxxxxxxxxx> Subject: RE: Developing cross-platform, accessible apps To: "programmingblind@xxxxxxxxxxxxx" <programmingblind@xxxxxxxxxxxxx> Date: Wednesday, June 16, 2010, 10:07 PM Hi, My knowledge of this kind of thing is shallow, so I hope that I'm going to ask this question correctly. Let's just say that you know that you want a platform to exhibit certain behaviors for accessibility reasons. For example, you know that every time you create a single line edit field that you need a label control to come with it. Further, you need certain properties set certain ways. Wouldn't you want to create an object that you could give to a developer that removes the burden of remembering to write the code a certain way, and at least, as a minimum, even if the developer does nothing, you get sensible results? Take our single line edit control. You'd probably use a name property to differentiate it from the other controls in your program. Maybe it would have a default constructor that would somehow create a label control whose control name would start with something like lbl and then end with the name of the single line edit control. And if the developer doesn't put in a value that would display to the screen, the label control's constructor or some other method would fill that in. I know that I have to be missing something, but as I said, my knowledge in this area is limited. Thanks. Jim Jim Homme, Usability Services, Phone: 412-544-1810. Skype: jim.homme Internal recipients, Read my accessibility blog. Discuss accessibility here. Accessibility Wiki: Breaking news and accessibility advice -----Original Message----- From: programmingblind-bounce@xxxxxxxxxxxxx [mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Roopakshi Pathania Sent: Wednesday, June 16, 2010 12:02 PM To: Jamal Mazrui Cc: programmingblind@xxxxxxxxxxxxx; program-l@xxxxxxxxxxxxx Subject: Re: Developing cross-platform, accessible apps Hmm, staying clear of this debate, I can only say that Java does have a powerful accessibility API and assistive technologies do (sometimes) take advantage of the API to provide access to their users. The only difficulty is that no assistive technology can take full advantage of the inbuilt accessibility API for now. While there are Swing based applications that are fully accessible, in fact MathTrax is a good example; many applications remain inaccessible either because of the limitations of the bridge, or because developers have their own style of coding which often doesn’t include techniques that would make an app accessible. This neglect on the part of the developers for not implementing practices like programmatically associating a control with its label is common in all programming languages. But Swing based applications also get a bad name because information on how to use them is not documented at a centralized place. Things like reinstalling the bridge every time you upgrade the JVM, using CTRL-Tab to move out of a table, and using F10 to focus on the menu are not generally known. Anyway, coming back to the actual topic, you also have wxPerl that would provide cross-platform accessibility. http://wxperl.sourceforge.net/
Regards --- On Sun, 6/13/10, Jamal Mazrui <empower@xxxxxxxxx> wrote: > From: Jamal Mazrui <empower@xxxxxxxxx> > Subject: Re: Developing cross-platform, accessible apps > To: "Roopakshi Pathania" <r_akshi_tgk@xxxxxxxxx> > Cc: programmingblind@xxxxxxxxxxxxx, program-l@xxxxxxxxxxxxx > Date: Sunday, June 13, 2010, 8:58 PM > This reminds me of a debate related > to Section 508 accessibility > standards. Some argue that a software application > should be considered > accessible if it implements the main accessibility API of > the platform, > e.g., if a Java app implements the Java access API. > Others argue that > functional performance must also be considered as well as > design specs. > So, if relevant assistive technology does not > support that API, then, > in practice, the app is inaccessible even though, in > theory, it could or > should be accessible. > > Proponents on one side say that it is optimal for the > responsibility for > accessibility to be divided among different parts of the > ecosystem that > necessarily must work together to achieve > accessibility. If assistive > technologies do not take advantage of an API that is > availble, they are > at fault, not the application, and it is important for AT > to meet its > responsibility on behalf of users with disabilities. > Without such an > expectation on AT, its vendors will lack sufficient > incentive to support > APIs that are critical for accessibility. > > Proponents on the other side say that idea sounds good in > principle, but > the result can be that users with disabilities are set back > by > inaccessible apps in their work and personal lives, a > reality that is > unacceptable. > > Jamal > > > > On 6/13/2010 12:21 AM, Roopakshi Pathania wrote: > > > > Hi Jamal, > > > > Well Most major screen readers support working with > Swing, even if a screen reader like Window Eyes uses a > different approach. I’ve checked and Hal also supports the > bridge. > > Besides, it’s not possible to dismiss access to > Swing based applications out of hand especially because > Swing components are widely used in software developed for > corporate environment. SAP and Oracle, both state the need > of using Java Access Bridge on their accessibility > requirements page. > > > > Java Access Bridge is probably the crux of the problem > because it does not expose the entire Java accessibility API > to a screen reader. > > If anyone is interested, here is a forum for > discussing accessibility of Java for developers who want to > make their software accessible. > > http://forums.sun.com/forum.jspa?forumID=3&start=0
> > > > If you go through some of the posts, you’ll realize > the kind of limitations Java Access Bridge imposes on > assistive technology. > > > > I quite agree with Ken, we do need a better bridge to > Java’s accessibility API. > > This might be possible if we try to get developers > (from the general community) interested in this project. > > > > Regards > > > > --- On Sat, 6/12/10, Jamal Mazrui<empower@xxxxxxxxx> > wrote: > > > >> From: Jamal Mazrui<empower@xxxxxxxxx> > >> Subject: Re: Developing cross-platform, accessible > apps > >> To: programmingblind@xxxxxxxxxxxxx > >> Cc: "Roopakshi Pathania"<r_akshi_tgk@xxxxxxxxx>, > program-l@xxxxxxxxxxxxx > >> Date: Saturday, June 12, 2010, 11:54 PM > >> Hi Roopakshi, > >> I am aware of the Java access API, but > unfortunately, I do > >> not think > >> there is sufficient screen reader support for it > on > >> Windows. This is > >> more the fault of the screen reader companies than > Sun, > >> since the API is > >> strong on the server side. > >> > >> Window-Eyes, for example, does not support that > API at > >> all. JAWS works > >> partially. I hear that NVDA works > well. I do > >> not know about System > >> Access or Hal. With the SWT approach, on the > other > >> hand, apps can be > >> fully accessible because native widgets are used, > including > >> > >> MSAA-integrated controls on Windows. > >> > >> Thanks for the info about Axtk, which I had not > heard > >> about. At first, > >> I thought the name was associated with the > cross-platform > >> GUI library > >> called TK, which has poor accessibility, but I see > that it > >> is actually > >> wx-related, as you say. > >> > >> Jamal > >> > >> On 6/12/2010 11:53 AM, Roopakshi Pathania wrote: > >> > > >> > Hi Jamal, > >> > > >> Thanks for the info about Axtk -- I had not heard > of > >> it. The name made > >> me first think it was related to the > cross-platform GUI > >> library called > >> TK, which has poor accessibility, but I see that > it is > >> based on > >> wxWdigets, as you say. > >> > >> Jamal > >> > >> > >> > >> On 6/12/2010 11:53 AM, Roopakshi Pathania wrote: > >>> > >>> Hi Jamal, > >>> > >>> > >>> You left out Java Accessibility API that > provides > >> access to Swing based applications on all > platforms (not > >> completely sure about Mac) through Java Access > Bridge. > >>> In this regard, the guidelines laid down by > IBM on > >> developing a completely accessible Java > application are > >> quite useful. > >>> http://www-03.ibm.com/able/guidelines/software/accesssoftware.html
> >>> > >>> I like to point the developers of > inaccessible > >> applications to this page. > >>> > >>> One more toolkit might be of interest: AxTk. > >>> http://code.google.com/p/axtk/
> >>> > >>> It is built on wxWidgets and is especially > geared > >> towards screen reader users. It is also suppose to > have text > >> to speech wrapper class supporting a number of > speech > >> engines. > >>> > >>> I’m building my own tools for financial and > data > >> analysis, so have looked at cross-platform > accessible > >> libraries. > >>> > >>> Regards > >>> Roopakshi > >>> > >>> --- On Sat, 6/12/10, Jamal Mazrui<empower@xxxxxxxxx> > >> wrote: > >>> > >>>> From: Jamal Mazrui<empower@xxxxxxxxx> > >>>> Subject: Developing cross-platform, > accessible > >> apps > >>>> To: "programmingblind"<programmingblind@xxxxxxxxxxxxx>, > >> program-l@xxxxxxxxxxxxx > >>>> Date: Saturday, June 12, 2010, 8:27 PM > >>>> This is to share some points I have > >>>> learned about developing cross-platform, > >> GUI-accessible, > >>>> desktop apps. Currently, the key is > using > >> programming > >>>> libraries that wrap native widgets of the > >> platform. These > >>>> native widgets generally implement the > main > >> accessibility > >>>> API of the platform, much more so than > custom > >> widgets. > >>>> > >>>> On Windows, native widgets are most likely > to > >> implement > >>>> Microsoft Active Accessibility, or > >> increasingly, User > >>>> Interface Automation as it replaces > MSAA. On > >> Linux, > >>>> the GTK+ widgets that are native to the > Gnome > >> desktop > >>>> implement the Assistive Technology > Service > >> Provider > >>>> Interface. On the Mac, Cocoa-based > widgets > >> implement the Mac > >>>> Accessibility Protocol. > >>>> > >>>> Thus, a cross-platform library is most > likely to > >> create > >>>> accessible GUIs if it wraps native widgets > of each > >> platform, > >>>> rather than defining its own > widgets. A > >> disadvantage > >>>> of this approach is that the developer > needs to be > >> conscious > >>>> of small differences in the behavior of > widgets > >> across > >>>> platforms, even though wrapping code of > the > >> library tries to > >>>> minimize such differences. Besides > >> accessibility, an > >>>> advantage of this approach is that widgets > have > >> the look and > >>>> feel that sighted users are accustomed to > >> experiencing on > >>>> each platform. > >>>> > >>>> Sometimes, a GUI library is closely > associated > >> with a > >>>> programming language that has especially > strong > >> support for > >>>> that library in wrapper functions and > design > >> tools. A > >>>> few language and library combinations that > seem to > >> work > >>>> particularly well for cross-platform, > accessible > >> development > >>>> are as follows: > >>>> > >>>> * Java and the Standard Widget > Toolkit > >>>> http://www.eclipse.org/swt/
> >>>> > >>>> * Python and wxWidgets > >>>> http://wxPython.org
> >>>> > >>>> * C# and the System.Windows.Forms > classes of > >> the Mono > >>>> Framework > >>>> http://mono-project.org
> >>>> > >>>> Note that, in this case, the Microsoft > .NET > >> Framework > >>>> should be used as the runtime environment > on > >> Windows in > >>>> order to have native widget support. > >>>> http://msdn.microsoft.com/en-us/netframework/default.aspx
> >>>> > >>>> If others have further info or ideas on > this > >> topic, please > >>>> share. > >>>> > >>>> Jamal > >>>> > >>>> __________ > >>>> View the list's information and change > your > >> settings at //www.freelists.org/list/programmingblind
> >>>> > >>>> > >>> > >>> > >>> > >>> __________ > >>> View the list's information and change your > settings > >> at > >>> //www.freelists.org/list/programmingblind
> >>> > >>> > >> > > > > > > > > > __________ > View the list's information and change your settings at > //www.freelists.org/list/programmingblind
> > __________ View the list's information and change your settings at //www.freelists.org/list/programmingblind
This e-mail and any attachments to it are confidential and are intended solely for use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this e-mail without the author's prior permission. The views expressed in this e-mail message do not necessarily represent the views of Highmark Inc., its subsidiaries, or affiliates. V'°¶¥ŠËlŠwè®fŠ‰Ú�×!jxÊ‹«±ëmŠx,jØm¶ŸÿÃ祊Ël¢¸?–+-þšè‚¶¦š)ànX§
__________ View the list's information and change your settings at //www.freelists.org/list/programmingblind __________View the list's information and change your settings at //www.freelists.org/list/programmingblind
