Created attachment 9143 [details]
a11y test report

fyi. was going to list missing mnemonics as a separate bug but the
a11y report covers it.

Thanks for the report. Some of the text fields were using a JCheckBox
as a "label" (e.g. Due Date, Subtask Of, Associated File). These both
enabled, and described the field on the right (due date, or subtask
field).  However, JCheckBox doesn't have a "label-for" attribute. I
guess that makes sense, since selecting the mnemonic takes the
keyboard focus to the checkbox itself, not the associated component.

So ... I introduced an additional label between the check box and the
component. For example:

[x] Due                Date: ______________ [....]

[ ] Associated File    Name: ____________

(Got rid of the Subtask Of as described in a different issue)

Now there's a separate mnemonic for the checkbox and the label with
labelfor.   Does this look right to you?  It looks slightly weird....
perhaps I should put the checkbox on its own line? Or do you have some
better solution?

I believe that since many of the components weren't pointed to by
labels (using setLabelFor), this caused them not to have accessible
names, which they otherwise obtain from the JLabel. Thus, I think/hope
the accessible name warnings will go away.  That leaves accessible
descriptions.

Putback fixes for labelFor.

i agree that having a checkbox and a labeled text field is odd. 

can we just do away with the check box? if either of the fields are
are blank then there isn't a file or a date associated with the task.

Associated File: |_______________| [...]
Due Date: |______________________|

that seems simpler to me. 

"Associated File: |_______________| [...]"
The problem with this is that the tasklist tries to be helpful, and
ALWAYS populates the file text field with the current editor file and
cursor position. That way, if you decide that yes, this task is
related to what I'm looking at, you just need to check the checkbox.
Without the checkbox, I'll either need to stop prepopulating the
textfield with the current position, or all tasks will get the current
position associated with them - which is misleading when the task has
nothing to do with it ("buy flowers for mother's day") - and even
misleading, since double clicking on the task will open up the source
file and put an annotation on the given line.

i suspected there was something like this going on. :-)

so go back to the way it was before with the check box and the
textfield (minus the additional label). make sure the textfield has an
a11y name and description and you don't need to worry abou the
LABEL_FOR error. 

sorry for the run around on this.

I've updated the dialog so that it should be a11y compliant now. Would
you mind running the accessibility checker again (once version 0.9.0
of the usertask module becomes available on the update center, or if
you can build from CVS trunk yourself) and let me know if there's
anything I forgot?

a couple of things:

-the a11y issues that opened this bug are all fixed. thanks.

-there are more a11y bugs for the dialogs i failed to test the first
time around... my mistake. i've included the test files and my
comments on what to do with the issues will be found in the included
files.

Created attachment 9271 [details]
a11y test report for fix dialog

Created attachment 9272 [details]
a11y test report for edit types dialog

Created attachment 9273 [details]
a11y test report for find dialog

Thanks for creating those a11y reports, Chris. Would you mind
rerunning the one on the Edit Types dialog using the current build,
since Tim has changed the dialog significantly (now uses a table, as
discussed at the UI review, instead of multiple list boxes.)

the revised edit types... dialog looks good from and a11y standpoint.
there are some errors for the check boxes that aren't obvious from
looking at the dialog i tested (probably depends on the content in the
table) so i can only suggest to make sure the contents of the table
(checkboxes and text) all get an a11y name and description -for
checkboxes the name of the column should function as the name and the
state as the description. the text should have the name of the column
as the name and the actual text as the description.

the dialog looks good though i'd suggest adding a label for both the
table and the description text area so it's easier to work out what
each is and how they're related:

Recognized Types:
+----------------------------------+
|                                  |
|     types table here             |
|                                  |
+----------------------------------+

Description:
+----------------------------------+
|                                  |
|     description text             |
|                                  |
+----------------------------------+

Created attachment 9330 [details]
a11y test results for Edit Types dialog

NOS1S5 - the Task module is not part of Sun ONE Studio.

This isssue is nearly fixed. The only thing remaining now is the lack
of accessibility descriptions on the checkboxes in the Edit Types...
dialogs.  So I'm downgrading the bug.

(By the way - do you think "Category" is a better ui name for
suggestion types than "type" ?  E.g. Edit Categories?)

I'm puzzled by this last part. There are no checkboxes in the Edit
Types dialog - only a JTable showing Booleans - so in the table's
model the method 
  public Class getColumnClass(int columnIndex) {
returns Boolean.class for the columns where we want checkboxes.

But this shouldn't place a checkbox in the component hierarchy, it
should just use a JCheckBox as a cell renderer. E.g. the cell renderer
checkbox is shared for all cells! So how can I put an accessibility
descriptor on it?  For that matter, how is this done in tables in general?

sorry for the delay -the update mail got burried:

yes, category is better than type.

not sure about the checkbox issue... i've quickly looked through
a11y.netbeans.org and haven't found anything that really addresses
this issue. 

if all the other issues have been fixed then i think we're doing
alright. a little more research will turn up what to do with the
checkboxes in the tree.

I think this should be tracked in task list component.

Please evaluate, all A11Y P3 should be evaluated. If it's not part of
release36, reassign to proper subcomponent. Thanks.

This ui is not part of standard nb realease
-> moving to "Other" subcomponent.

it's already fixed IMHO

4.1 is out