Revision of XUL accessibility guidelines

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

Revision of XUL accessibility guidelines

Shane Anderson
Hi all

WebAIM has been working on an expanded revision of the accessibility
guidelines. A first rough draft is available at the following url:

http://webaim.org/temp/mozilla/xul_accessibility_guidelines.html


We have worked hard on the guidelines but you will notice that some sections
could use some more content/examples. Please let us know if you have any
ideas. We have found this project harder than anticipated due to the fact
that there is not a large corpus of XUL apps out there from which we can
extract patterns of inaccessible implementation. We have tried to keep the
guidelines terse and have tried to link to existing resources and examples.

Your feedback is appreciated.

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

Re: Revision of XUL accessibility guidelines

Aaron Leventhal-3
Thanks Shane. Looks good so far. Here is some
feedback.

Intro:
"Larger applications should be checked with a
screen reader."
-> Add something like "Testing with a screen
reader is in many ways the best test, because both
the keyboard navigation and underlying
semantics/structure of the UI can be tested at the
same time. It is an excellent indicator regarding
the accessibility of a user interface, but is by
no means a complete test. Ultimately, for
applications that must be completely accessible,
the best test is to have a variety of end users
-> JAWS 7.1 probably has equivalent XUL support
when compared with Window-Eyes. Instead of saying
Window-Eyes is specifically better, it is probably
best to link to the wiki with up-to-date AT
compatibility:
http://kb.mozillazine.org/Assistive_technology_compatibility 
    (in fact this wiki page should be edited to
point to product demos)
"in some areas accessibility is spotty"
-> This is probably unintentionally slightly too
negative. How about "in a few areas such as x, y
and z" accessibility gaps remain. Better yet would
be a section that describes "Unresolved
Accessibility Issues in XUL" -- perhaps pointing
to bugs so readers can check if the issues have
been fixed yet.
"Mozilla offers a great accessibility"
-> The word forum should be part of that link text

Keyboard Access:
-> I think the table has too many columns. I
suggest either keeping Pass or Fail and removing
one. They're redundant. Also, the Notes column
should only show up in the printable version. Can
you make it disappear unless @media print is used?
"Tab order jumps around in not a logical order"
-> Awkward. Also not clear what logical means.
Usually this is a subset of the typical reading
order (left to right, top to bottom except in
Hebrew and Arabic, correct?)
"Column picker"
-> I wasn't sure what this was at first myself,
but now I know. Perhaps a glossary at the end?
"Keyboard shortcuts are present for important
functionality and do not interfere with other
applications such as assistive technologies."
I'd remove the bit about interference with
assistive technologies. Each AT has it's own set
of keystrokes and it wouldn't be practical to list
them all. Not only that, but you'd have no
keystrokes left to use. It's the AT's job to allow
for keyboard reassignment and a pass through key.
"Some operations rely only on mouse use"
-> "Operations exist that rely on mouse use alone"
( for some reason this sounds clearer to me).
"Scrolling can not"
-> Scrolling cannot (extra space removed)

Tab order:
"through menu items or the context menu (right
click menu)"
-> I'm uncomfortable calling it the right click
menu. I see this text repeated. The way out of
this is to use the glossary as mentioned before,
and define what a context menu is. I suggest using
the context menu key image from the orginal
guidelines.
Trees:
"until these problems are solved"
-> This is typical of tree widgets in today's
toolkits. What Mozilla does is follow the behavior
of the tree view on the target platform. That's by
design. I'd be open to discuss solutions but we
shouldn't suggest there is one on the table,
because there isn't yet. I don't know of a GUI
toolkit that gets around that, although my
understand is that Vista makes column headers key
navigable, so my guess is that Mozilla will at
some point change that as well, at least for Vista.
Toolbar buttons:
-> I suggest linking to the alternative text
section since many (most?) toolbar buttons are
just images with no text at all.
-> It is possible to make toolbarbuttons key
navigable via a trick. class="tabbable"   For
example we do that in the print preview screen
where there is no main menu.
-> The more general way to make something tabbable
is a CSS rule -moz-user-focus: normal   -- we need
to discuss that somewhere, I believe.
Maintaining focus:
-> A real example of focus being disabled is in a
reorderable list with buttons to the side "Move
up" and "Move down". After hitting space on move
down, an item may be at the end of the list in
which case the "Move down" button is no longer
relevant and becomes disabled. However, the user's
focus is still there. I think Mozilla will
automatically move focus to the next focusable
item (hopefully there is one). I don't see a
better way at the moment. Open to suggestions.
-> The problem isn't just if the current item
becomes disabled, hidden or destroyed. It could be
any ancestor of the focus.
-> It could be these issues are automatically
handled by Mozilla by putting focus on the next
item. Have you done any testing to verify the
statement in this section that doing those things
can cause a loss of focus? It may no longer be true.

Testing keyboard access:
"to ensure that they do not interfere with
assistive technologies and other applications."
-> Same comment as before about interference with
AT's. No way to deal with that, I'd remove that
unless you have an example of what the author
should not do.

Cropping:
This is only a problem if the XUL author specially
codes for it. For example, XUL trees automatically
use ... for cropping, but the screen reader still
reports the full string.

Assistive information:
"Information displayed on screen is not always
understandable by assistive technologies"
-> I find this an awkward opening. Perhaps remove
or move it?

Form labels:
-> I believe XUL, like HTML, allows the author to
use the <label> element as a parent to both the
label text and the form control. THere are a
number of valid different ways to use it, which
should be shown here in the code sample as correct.
In the privacy panel image there is a prompt "[ ]
Remember visited pages for the last ____ days"
-> The only way to deal with that is via
aaa:labelledby. So, while I don't think you need
to deal with ARIA much, I think this is one case
where you need to show the technique. One other
place is for aaa:describedby. Any floating static
text descriptions should be tied to a form control
or container element. Alternatively you can also
now use <description control="[id]"> similar to
the <label> element.

Testing assistive information:
-> Assistive information  is a new phrase for me.
I've heard of "semantics" before etc. How about a
glossary entry?
"view the code and heck"
-> Spelling error for heck -> check

Color:
-> I think system colors can be used via CSS. See
http://www.w3.org/TR/REC-CSS2/ui.html#system-colors
-> Some of those items work. There are also some
-moz color values. I'm not totally sure where they
fit in.

System defaults:
-> Similar comment as for button. I believe
there's always a way to use CSS to specify the
system default, and leaving the CSS rule out
should default to that.

Emphasizing text:
-> Please explain that HTML can be used within XUL
to display text.
-> Do you mean emphasized text in form control
labels or descriptions? You wouldn't want to use
HTML in a menuitem for example.
-> However, since XUL UI is not read in doc
reading mode by screen readers, I'm not sure doing
labels or descriptions in HTML will actually help
in any way. How will the end user benefit if the
AT ignores it?

Flexible sizing:
"Some of the same functionality is found in CSS,
but should be avoided"
-> Not clear why it should be avoided

Testing display:
-> I think it's useful to explain more details on
how to do this on various platforms. The old
guidelines say "Ensure compatibility with system
themes, such as the high contrast theme on Windows
(available via Left-alt + Left-shift +
Printscreen)." I don't think we should remove that.

Alerts:
Need to differentiate between alerts inside the
current window and alert dialogs (which have their
own window).

Some things I think that are missing:
oncontextmenu technique
 From the previous guidelines "Avoid small targets
which are difficult to see and click on." --
that's often a problem in status bars for example.
Some feature relies on use of a tiny button.



Shane Anderson wrote:

> Hi all
>
> WebAIM has been working on an expanded revision of the accessibility
> guidelines. A first rough draft is available at the following url:
>
> http://webaim.org/temp/mozilla/xul_accessibility_guidelines.html
>
>
> We have worked hard on the guidelines but you will notice that some
> sections
> could use some more content/examples. Please let us know if you have any
> ideas. We have found this project harder than anticipated due to the fact
> that there is not a large corpus of XUL apps out there from which we can
> extract patterns of inaccessible implementation. We have tried to keep the
> guidelines terse and have tried to link to existing resources and examples.
>
> Your feedback is appreciated.
>
> Thanks
> The WebAIM team
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Revision of XUL accessibility guidelines

Aaron Andersen-2
Aaron Leventhal wrote:
> Thanks Shane. Looks good so far. Here is some
> feedback.

I think I have most of this dealt with. The newish version of the
guidelines (with changes by me based on your feedback) is at
http://webaim.org/temp/mozilla/guidelines1.1.html

I am in the process of testing some larger changes and preparing to put
the whole thing into DevMo for permanent storage, although we are
definitely still soliciting feedback from community members on any or
all of it.


> Intro:
> "Larger applications should be checked with a
> screen reader."
> -> Add something like "Testing with a screen
> reader is in many ways the best test, because both
> the keyboard navigation and underlying
> semantics/structure of the UI can be tested at the
> same time. It is an excellent indicator regarding
> the accessibility of a user interface, but is by
> no means a complete test. Ultimately, for
> applications that must be completely accessible,
> the best test is to have a variety of end users

This sentence kind of cuts off, so I'm not
quite sure what it was meant to say at the end.
I added it in place of the old sentence, with
some words tacked onto the ending so it sounds
somewhat complete.


> -> JAWS 7.1 probably has equivalent XUL support
> when compared with Window-Eyes. Instead of saying
> Window-Eyes is specifically better, it is probably
> best to link to the wiki with up-to-date AT
> compatibility:
> http://kb.mozillazine.org/Assistive_technology_compatibility
>     (in fact this wiki page should be edited to
> point to product demos)

Edited the guidelines to point to the kb article.
The whole intro still feels clunky to me (and I
probably just made it worse with my edits) but I'm
not going to try rewriting the whole thing just yet.


> "in some areas accessibility is spotty"
> -> This is probably unintentionally slightly too
> negative. How about "in a few areas such as x, y
> and z" accessibility gaps remain. Better yet would
> be a section that describes "Unresolved
> Accessibility Issues in XUL" -- perhaps pointing
> to bugs so readers can check if the issues have
> been fixed yet.

I agree about the usefulness of such a wiki page.
Any volunteers?

Edited the sentence to (I think) sound less negative.


> "Mozilla offers a great accessibility"
> -> The word forum should be part of that link text

Done. I almost think the whole paragraph should be
redone, but like I said I'm not going to try to
rewrite the entire intro just yet.


> Keyboard Access:
> -> I think the table has too many columns. I
> suggest either keeping Pass or Fail and removing
> one. They're redundant. Also, the Notes column
> should only show up in the printable version. Can
> you make it disappear unless @media print is used?

Made the notes column only show up when printed.
I agree that having pass and fail is mostly
redundant, but there are some cases where reading
the "fail" description could help point out a
problem that isn't so clear from the pass column.

If we only have one column, then it's not really a
table anymore and perhaps the whole thing would
better be presented as an unordered list. Or,
alternately, maybe the checklist should be its
own document, separate from the guidelines.


> "Tab order jumps around in not a logical order"
> -> Awkward. Also not clear what logical means.
> Usually this is a subset of the typical reading
> order (left to right, top to bottom except in
> Hebrew and Arabic, correct?)

Changed the sentence, although mine might not be
all that much better than the original. A
discussion of what constitutes a logical or correct
tab order is (or should be) in the tab order
section, with the checklist only there to serve
as a reminder to someone who is already somewhat
familiar with the concept.


> "Column picker"
> -> I wasn't sure what this was at first myself,
> but now I know. Perhaps a glossary at the end?

That wouldn't be a bad idea, or maybe just a
small screenshot of the column picker widget
the first time it is mentioned.


> "Keyboard shortcuts are present for important
> functionality and do not interfere with other
> applications such as assistive technologies."
> I'd remove the bit about interference with
> assistive technologies. Each AT has it's own set
> of keystrokes and it wouldn't be practical to list
> them all. Not only that, but you'd have no
> keystrokes left to use. It's the AT's job to allow
> for keyboard reassignment and a pass through key.

Removed from the checklist and the document
body. Shane and I had a sizable disagreement
about that part, where Shane said it should be
there and I said it shouldn't...


> "Some operations rely only on mouse use"
> -> "Operations exist that rely on mouse use alone"
> ( for some reason this sounds clearer to me).

How about "Operations exist that can only
be performed with a mouse."?


> "Scrolling can not"
> -> Scrolling cannot (extra space removed)

Done.


> Tab order:
> "through menu items or the context menu (right
> click menu)"
> -> I'm uncomfortable calling it the right click
> menu. I see this text repeated. The way out of
> this is to use the glossary as mentioned before,
> and define what a context menu is. I suggest using
> the context menu key image from the orginal
> guidelines.

Removed the phrase "right click menu" from the
document. I don't think explaning what the
context menu is is really necessary (we're
assuming a basic knowledge of GUI
programming here, aren't we?) although if
we had a glossary that could be included.

Perhaps we could find a generic glossary of
GUI components and terms, or a gloassary of
accessibility terms, and just link to them,
or find one that was in CC and just steal it.


> Trees:
> "until these problems are solved"
> -> This is typical of tree widgets in today's
> toolkits. What Mozilla does is follow the behavior
> of the tree view on the target platform. That's by
> design. I'd be open to discuss solutions but we
> shouldn't suggest there is one on the table,
> because there isn't yet. I don't know of a GUI
> toolkit that gets around that, although my
> understand is that Vista makes column headers key
> navigable, so my guess is that Mozilla will at
> some point change that as well, at least for Vista.
> Toolbar buttons:

Rewrote it so as not to imply that this is a bug
in XUL.


> -> I suggest linking to the alternative text
> section since many (most?) toolbar buttons are
> just images with no text at all.

Actually, most if not all toolbar buttons that
I can think of have text and icons, although the
text isn't shown by default. I can't say whether
a screen reader would read the text even if it
wasn't shown visually, since toolbar buttons
aren't in the tab order and are therefore usually
ignored completely by screen readers.


> -> It is possible to make toolbarbuttons key
> navigable via a trick. class="tabbable"   For
> example we do that in the print preview screen
> where there is no main menu.

What should we say about this? Is it correct,
from an a11y standpoint, to just make all your
toolbar buttons tabable, or would that be bad
since you're breaking convention? Should we say
only to use that when you have no other way of
making the same functionality available elsewhere,
or just that this is another way or doing it? I
would certainly think it would be advisable to
either have all your toolbar buttons (in a given
app or window) keyboard navigable or else none
of them...

Personally, I don't know why we can't just make
all toolbars keyboard navigable by default,
consistent with the way Microsoft Office (and
some other applications) do it. Is there a good
reason why this isn't the case?


> -> The more general way to make something tabbable
> is a CSS rule -moz-user-focus: normal   -- we need
> to discuss that somewhere, I believe.

* I think I forgot to add that. I'll try to remember for my next edit.


> Maintaining focus:
> -> A real example of focus being disabled is in a
> reorderable list with buttons to the side "Move
> up" and "Move down". After hitting space on move
> down, an item may be at the end of the list in
> which case the "Move down" button is no longer
> relevant and becomes disabled. However, the user's
> focus is still there. I think Mozilla will
> automatically move focus to the next focusable
> item (hopefully there is one). I don't see a
> better way at the moment. Open to suggestions.

> -> The problem isn't just if the current item
> becomes disabled, hidden or destroyed. It could be
> any ancestor of the focus.

Noted.


> -> It could be these issues are automatically
> handled by Mozilla by putting focus on the next
> item. Have you done any testing to verify the
> statement in this section that doing those things
> can cause a loss of focus? It may no longer be true.

Testing on the "View->Character Encoding->Customize List..."
dialog results in the following: the "Move up" or
"Move down" buttons retains the focus indicator
even after being disabled. Tabbing moves normally
from there to the next element in the tab order.

However, some earlier testing we did reveals
some much crazier behaviour when the focus element
is actually destroyed instead of merely being disabled,
in the which case the focus either started over at
the beginning of the dialog or jumped ahead two
positions in the tab order instead of one.


> Testing keyboard access:
> "to ensure that they do not interfere with
> assistive technologies and other applications."
> -> Same comment as before about interference with
> AT's. No way to deal with that, I'd remove that
> unless you have an example of what the author
> should not do.

Removed. Rewrote it to say not to use keyboard
shortcuts in an extension that interfere with those
of the base application.


> Cropping:
> This is only a problem if the XUL author specially
> codes for it. For example, XUL trees automatically
> use ... for cropping, but the screen reader still
> reports the full string.

Removed the whole section. If anyone wants it
back, let me know.


> Assistive information:
> "Information displayed on screen is not always
> understandable by assistive technologies"
> -> I find this an awkward opening. Perhaps remove
> or move it?

Rewrote the sentence, but I'm not sure mine is
any better than the original.


> Form labels:
> -> I believe XUL, like HTML, allows the author to
> use the <label> element as a parent to both the
> label text and the form control. THere are a
> number of valid different ways to use it, which
> should be shown here in the code sample as correct.
> In the privacy panel image there is a prompt "[ ]
> Remember visited pages for the last ____ days"

I wasn't able to get this to work, but maybe I was
coding it wrong. If anyone can verify that it is
indeed possible, let me know and I'll put it in.


> -> The only way to deal with that is via
> aaa:labelledby. So, while I don't think you need
> to deal with ARIA much, I think this is one case
> where you need to show the technique. One other
> place is for aaa:describedby. Any floating static
> text descriptions should be tied to a form control
> or container element. Alternatively you can also
> now use <description control="[id]"> similar to
> the <label> element.

I would be disappointed if we had to resort to
this, because like it amounts to telling people
they have to learn a completely different language
in order to make XUL accessible, whereas we told
them before that XUL had accessibility features
built-in. I also think that's where you'd end up
scaring off people and maybe doing more harm then
good. It's too bad we couldn't add a XUL widget or
attribute that would encapsulate the aaa stuff over
in XBL and make it easier for end users to use those
features.

However, I'm certainly not in charge here, so if
the general consensus is that aaa: needs to be in
the guidelines, then somebody please point me to
some documentation where I can learn the aaa: stuff
so I can write about it.

> Testing assistive information:
> -> Assistive information  is a new phrase for me.
> I've heard of "semantics" before etc. How about a
> glossary entry?

I've never heard of it either. Google only has
766 pages containing the phrase "assistive information",
so I think it's fair to say that it isn't a very
widely used term. Maybe we should replace it with
something more common. Anybody got a suggestion?


> "view the code and heck"
> -> Spelling error for heck -> check

Fixed.


> Color:
> -> I think system colors can be used via CSS. See
> http://www.w3.org/TR/REC-CSS2/ui.html#system-colors
> -> Some of those items work. There are also some
> -moz color values. I'm not totally sure where they
> fit in.

True, but I believe they are deprecated because
looking native takes more than just matching
colors these days. If it is correct that widgets
look native by default (somebody correct me if
this isn't the case), then I wouldn't think we
would need to discuss how to do it manually.


> System defaults:
> -> Similar comment as for button. I believe
> there's always a way to use CSS to specify the
> system default, and leaving the CSS rule out
> should default to that.

Which is exactly what the guidelines say,
isn't it?


> Emphasizing text:
> -> Please explain that HTML can be used within XUL
> to display text.
> -> Do you mean emphasized text in form control
> labels or descriptions? You wouldn't want to use
> HTML in a menuitem for example.
> -> However, since XUL UI is not read in doc
> reading mode by screen readers, I'm not sure doing
> labels or descriptions in HTML will actually help
> in any way. How will the end user benefit if the
> AT ignores it?

It probably won't. This is another one of those
"Shane thought it should be there" issues, where
now that he's gone we can take it out (since I
didn't really agree with him from the start). :)


> Flexible sizing:
> "Some of the same functionality is found in CSS,
> but should be avoided"
> -> Not clear why it should be avoided

Because CSS positioning sucks. What this is
trying to say is, XUL has a flexible box model
that is perfect for laying out controls, and
that even though it might work some of the
time, one shouldn't try to use css
position: and float: etc to layout a XUL
app.  hbox, vbox, grid, stack, deck, etc should
provide all the positioning you'd ever need.

I actually heard rumors that there was talking
of trying to backport the XUL positioning
model to html. Now that would be nice...


> Testing display:
> -> I think it's useful to explain more details on
> how to do this on various platforms. The old
> guidelines say "Ensure compatibility with system
> themes, such as the high contrast theme on Windows
> (available via Left-alt + Left-shift +
> Printscreen)." I don't think we should remove that.

If anyone knows an equivalent thing for linux or
mac, let me know and we can list them all. Otherwise,
I'll just put the windows example back in the way
it used to be.


> Alerts:
> Need to differentiate between alerts inside the
> current window and alert dialogs (which have their
> own window).

Are we really going to have alerts inside the window
commonly? Shane was pretty convinced that we had to
talk about notificationbox here, but as I see it
notificationbox is really only useful on a browser
element, so it's not something 99% of all XUL
developers will ever need to worry about.

The part about not using audio or visual stuff alone
for an alert is good. I don't know what else we need
to say as far as differentiating between inside-the-
window alerts and outside-the-window ones.


> Some things I think that are missing:
> oncontextmenu technique

Added something to the effect to the keyboard
access section.


>  From the previous guidelines "Avoid small targets
> which are difficult to see and click on." --
> that's often a problem in status bars for example.
> Some feature relies on use of a tiny button.

Added to a section called "Interactive Elements"
along with a few other things that might be important.


And I think that's it....

Aaron

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

Re: Revision of XUL accessibility guidelines

Aaron Leventhal-3
[hidden email] wrote:

>> "in some areas accessibility is spotty"
>> -> This is probably unintentionally slightly too
>> negative. How about "in a few areas such as x, y
>> and z" accessibility gaps remain. Better yet would
>> be a section that describes "Unresolved
>> Accessibility Issues in XUL" -- perhaps pointing
>> to bugs so readers can check if the issues have
>> been fixed yet.
>
> I agree about the usefulness of such a wiki page.
> Any volunteers?
It doesn't take long to set one up. If you don't
want to do that, I at least want a list of all
issues WebAIM knows about, as an email to this
newsgroup. Or file them as bugs, whichever you prefer.
>
> Made the notes column only show up when printed.
> I agree that having pass and fail is mostly
> redundant, but there are some cases where reading
> the "fail" description could help point out a
> problem that isn't so clear from the pass column.
Can you use width parameters to make the columns
of the sub tables visually line up?

>> "Some operations rely only on mouse use"
>> -> "Operations exist that rely on mouse use alone"
>> ( for some reason this sounds clearer to me).
>
> How about "Operations exist that can only
> be performed with a mouse."?
Good

> Removed the phrase "right click menu" from the
> document. I don't think explaning what the
> context menu is is really necessary (we're
> assuming a basic knowledge of GUI
> programming here, aren't we?) although if
> we had a glossary that could be included.
I've worked with engineers who didn't know that
name for it. Better to explain it.

> Perhaps we could find a generic glossary of
> GUI components and terms, or a gloassary of
> accessibility terms, and just link to them,
> or find one that was in CC and just steal it.
I think we just need to include the terms used in
this document. Not that many really.

>> -> I suggest linking to the alternative text
>> section since many (most?) toolbar buttons are
>> just images with no text at all.
>
> Actually, most if not all toolbar buttons that
> I can think of have text and icons, although the
> text isn't shown by default. I can't say whether
> a screen reader would read the text even if it
> wasn't shown visually, since toolbar buttons
> aren't in the tab order and are therefore usually
> ignored completely by screen readers.
Examples of textless toolbarbuttons: Home, Back,
Forward, Stop in Firefox.

People sometimes use something like "JAWS cursor
mode" to explore the toolbars and other objects on
the screen. The alternative text is important if
just for that. In addition, low vision users (like
ZoomText users) will often point at objects on the
screen and expect a tooltip and/or spoken text to
explain what the tooltip is. Besides, the tooltip
helps almost all users. It's not always clear what
an image is.

So, tooltiptext or some kind of displayed text is
necessary for toolbarbuttons. We need to provide
the techniques, whatever they are, for toolbarbutton.

>> -> It is possible to make toolbarbuttons key
>> navigable via a trick. class="tabbable"   For
>> example we do that in the print preview screen
>> where there is no main menu.
>
> What should we say about this? Is it correct,
> from an a11y standpoint, to just make all your
> toolbar buttons tabable, or would that be bad
> since you're breaking convention? Should we say
> only to use that when you have no other way of
> making the same functionality available elsewhere,
> or just that this is another way or doing it? I
> would certainly think it would be advisable to
> either have all your toolbar buttons (in a given
> app or window) keyboard navigable or else none
> of them...
Say to do it when there is no other way to access
the functionality, such as when there is no
menubar on the window. I agree with the all or
nothing tabbability idea.

> Personally, I don't know why we can't just make
> all toolbars keyboard navigable by default,
> consistent with the way Microsoft Office (and
> some other applications) do it. Is there a good
> reason why this isn't the case?
Mostly that no one has done it. We probably should
do it. Anyone know if Vista apps do this by default?

>
>> -> The more general way to make something tabbable
>> is a CSS rule -moz-user-focus: normal   -- we need
>> to discuss that somewhere, I believe.
>
> * I think I forgot to add that. I'll try to remember for my next edit.
Yes, please do.

>> Maintaining focus:
>> -> A real example of focus being disabled is in a
>> reorderable list with buttons to the side "Move
>> up" and "Move down". After hitting space on move
>> down, an item may be at the end of the list in
>> which case the "Move down" button is no longer
>> relevant and becomes disabled. However, the user's
>> focus is still there. I think Mozilla will
>> automatically move focus to the next focusable
>> item (hopefully there is one). I don't see a
>> better way at the moment. Open to suggestions.

>
>> -> The problem isn't just if the current item
>> becomes disabled, hidden or destroyed. It could be
>> any ancestor of the focus.
>
> Noted.
Where was that noted?

> Testing on the "View->Character Encoding->Customize List..."
> dialog results in the following: the "Move up" or
> "Move down" buttons retains the focus indicator
> even after being disabled. Tabbing moves normally
> from there to the next element in the tab order.
I think we have special code in that dialog for
the focus issue.

> However, some earlier testing we did reveals
> some much crazier behaviour when the focus element
> is actually destroyed instead of merely being disabled,
> in the which case the focus either started over at
> the beginning of the dialog or jumped ahead two
> positions in the tab order instead of one.
Okay. Sounds like something we should improve in
XUL (or actually everywhere in Mozilla more generally)

>> Form labels:
>> -> I believe XUL, like HTML, allows the author to
>> use the <label> element as a parent to both the
>> label text and the form control. THere are a
>> number of valid different ways to use it, which
>> should be shown here in the code sample as correct.
>> In the privacy panel image there is a prompt "[ ]
>> Remember visited pages for the last ____ days"
> I wasn't able to get this to work, but maybe I was
> coding it wrong. If anyone can verify that it is
> indeed possible, let me know and I'll put it in.
I'm not sure if it is valid, actually. We need to
check around.

>> -> The only way to deal with that is via
>> aaa:labelledby. So, while I don't think you need
>> to deal with ARIA much, I think this is one case
>> where you need to show the technique. One other
>> place is for aaa:describedby. Any floating static
>> text descriptions should be tied to a form control
>> or container element. Alternatively you can also
>> now use <description control="[id]"> similar to
>> the <label> element.
>
> I would be disappointed if we had to resort to
> this, because like it amounts to telling people
> they have to learn a completely different language
> in order to make XUL accessible, whereas we told
> them before that XUL had accessibility features
> built-in. I also think that's where you'd end up
> scaring off people and maybe doing more harm then
> good. It's too bad we couldn't add a XUL widget or
> attribute that would encapsulate the aaa stuff over
> in XBL and make it easier for end users to use those
> features.
>
> However, I'm certainly not in charge here, so if
> the general consensus is that aaa: needs to be in
> the guidelines, then somebody please point me to
> some documentation where I can learn the aaa: stuff
> so I can write about it.
We really only need it for labelledby. I want to
put it in, although the testing tool doesn't need
to test for it. People are coming to this document
to solve problems, and to get info. They won't
want us to remove things just because it's a
solution that's not pure XUL (we do mention HTML
after all, and part of the power of this platform
is to mix markup technologies).

It's not hard to use. Just put
xmlns:aaa="http://www.w3.org/2005/07/aaa"
and then instead of pointing from the label to the
control, you can do it in reverse, and provide a
list of IDs.

Here's an example of how to use it:
http://lxr.mozilla.org/seamonkey/source/browser/components/preferences/privacy.xul#105
It has an hbox containing a checkbox, textbox and
then a label. Both the checkbox and textbox are
labelledby all three children, because they all
have text associated with them.

Any other docs I could point you to will describe
a lot more than labelledby.

Also, please put <description control="[id]"> in
there.  That's pure XUL and very useful. It means
the description will get read aloud as the user
tabs to something.

>> Testing assistive information:
>> -> Assistive information  is a new phrase for me.
>> I've heard of "semantics" before etc. How about a
>> glossary entry?
>
> I've never heard of it either. Google only has
> 766 pages containing the phrase "assistive information",
> so I think it's fair to say that it isn't a very
> widely used term. Maybe we should replace it with
> something more common. Anybody got a suggestion?
I'm okay with it, actually. Since we'll be
wordsmithing later we can tweak it then if we come
up with something.

>
>
>> Color:
>> -> I think system colors can be used via CSS. See
>> http://www.w3.org/TR/REC-CSS2/ui.html#system-colors
>> -> Some of those items work. There are also some
>> -moz color values. I'm not totally sure where they
>> fit in.
>
> True, but I believe they are deprecated because
> looking native takes more than just matching
> colors these days. If it is correct that widgets
> look native by default (somebody correct me if
> this isn't the case), then I wouldn't think we
> would need to discuss how to do it manually.
Are you sure they're deprecated? If they aren't it
might be least useful to mention them and point to
a doc which contains them. People are always
getting creative in the development of custom
widgets and I would think that those hardcoded
colors are useful in some situations.

>> Emphasizing text:
It still needs to be removed from the quick
reference tables up top.

>> Flexible sizing:
>> "Some of the same functionality is found in CSS,
>> but should be avoided"
>> -> Not clear why it should be avoided
>
> Because CSS positioning sucks. What this is
> trying to say is, XUL has a flexible box model
> that is perfect for laying out controls, and
> that even though it might work some of the
> time, one shouldn't try to use css
> position: and float: etc to layout a XUL
> app.  hbox, vbox, grid, stack, deck, etc should
> provide all the positioning you'd ever need.
Okay, can you say "can be found in CSS
positioning". At first I thought it meant the flex
attributes etc. could be used in CSS.

>> Testing display:
>> -> I think it's useful to explain more details on
>> how to do this on various platforms. The old
>> guidelines say "Ensure compatibility with system
>> themes, such as the high contrast theme on Windows
>> (available via Left-alt + Left-shift +
>> Printscreen)." I don't think we should remove that.
>
> If anyone knows an equivalent thing for linux or
> mac, let me know and we can list them all. Otherwise,
> I'll just put the windows example back in the way
> it used to be.
Just put that one in for now. The Gnome one can be
simply done through the Gnome themes. There's no
shortcut. Don't know about Mac.

>> Alerts:
>> Need to differentiate between alerts inside the
>> current window and alert dialogs (which have their
>> own window).
>
> Are we really going to have alerts inside the window
> commonly? Shane was pretty convinced that we had to
> talk about notificationbox here, but as I see it
> notificationbox is really only useful on a browser
> element, so it's not something 99% of all XUL
> developers will ever need to worry about.
It looks like you already mention both. Just make
sure you say "alert dialog" whenever you mean an
alert with its own window.

"Avoid moving interactive elements around. "
-> Might want to make that a little clearer.
Perhaps break that paragraph up so you can explain
each item better.
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Revision of XUL accessibility guidelines

Aaron Andersen-2

Aaron Leventhal wrote:

> [hidden email] wrote:
> >> "in some areas accessibility is spotty"
> >> -> This is probably unintentionally slightly too
> >> negative. How about "in a few areas such as x, y
> >> and z" accessibility gaps remain. Better yet would
> >> be a section that describes "Unresolved
> >> Accessibility Issues in XUL" -- perhaps pointing
> >> to bugs so readers can check if the issues have
> >> been fixed yet.
> >
> > I agree about the usefulness of such a wiki page.
> > Any volunteers?
> It doesn't take long to set one up. If you don't
> want to do that, I at least want a list of all
> issues WebAIM knows about, as an email to this
> newsgroup. Or file them as bugs, whichever you prefer.

I'm in the process of learning how to use the DevMo wiki, styles,
templates, etc. to put this document up, so I could definitely set up
another page once I get that done. However, I'm not sure that I know of
very many such bugs, other than the ones already mentioned here. Maybe
what we need is an "Unresolved A11y issues in XUL" metabug in bugzilla
that we can use to keep track of official bugs for all such issues
(perhaps in addition to an explanatory wiki page).


> > Made the notes column only show up when printed.
> > I agree that having pass and fail is mostly
> > redundant, but there are some cases where reading
> > the "fail" description could help point out a
> > problem that isn't so clear from the pass column.
> Can you use width parameters to make the columns
> of the sub tables visually line up?

Yes, it does look rather messed up as is. Sorry about that. Actually,
I'm currently think that the whole checklist should be a completely
separate page from the guidelines, and then we can just link to it
somewhere near the introduction. The checklist is certainly useful, but
more so when you're already familiar with the guidelines it's referring
to, so right up at the top (as the first thing you see) probably isn't
the best place for it.


> > Removed the phrase "right click menu" from the
> > document. I don't think explaning what the
> > context menu is is really necessary (we're
> > assuming a basic knowledge of GUI
> > programming here, aren't we?) although if
> > we had a glossary that could be included.
> I've worked with engineers who didn't know that
> name for it. Better to explain it.

We can do that. Any suggestions for how to explain it quickly in a way
that everyone will know what we're talking about?


> > Perhaps we could find a generic glossary of
> > GUI components and terms, or a gloassary of
> > accessibility terms, and just link to them,
> > or find one that was in CC and just steal it.
> I think we just need to include the terms used in
> this document. Not that many really.

OK. I'll look around for other terms that people might not understand,
and try to explain them the first time they're used. If you know of
specific others that you want explained, feel free to list them here.

> Examples of textless toolbarbuttons: Home, Back,
> Forward, Stop in Firefox.

As I said before, they're not really textless as much as that the text
isn't shown by default. (_Context menu -> Toolbar Properties -> Icons
and Text_ will show the text). Depending on how showing vs. not showing
the text is implemented in the backend, the screen reader still might
read the text even if it wasn't visible. Like I said, I'd have to test
to be sure (which I'll see if I can find time to do one of these days).


> People sometimes use something like "JAWS cursor
> mode" to explore the toolbars and other objects on
> the screen. The alternative text is important if
> just for that. In addition, low vision users (like
> ZoomText users) will often point at objects on the
> screen and expect a tooltip and/or spoken text to
> explain what the tooltip is. Besides, the tooltip
> helps almost all users. It's not always clear what
> an image is.
>
> So, tooltiptext or some kind of displayed text is
> necessary for toolbarbuttons. We need to provide
> the techniques, whatever they are, for toolbarbutton.

I would say that for full accessibility they should probably have both
(text and tooltiptext, like back, forward, reload, etc). Then it's up
to the user to decide if he wants to see the icons (with tooltiptext),
the button text, or both.


> >> -> It is possible to make toolbarbuttons key
> >> navigable via a trick. class="tabbable"   For
> >> example we do that in the print preview screen
> >> where there is no main menu.
> >
> > What should we say about this? Is it correct,
> > from an a11y standpoint, to just make all your
> > toolbar buttons tabable, or would that be bad
> > since you're breaking convention? Should we say
> > only to use that when you have no other way of
> > making the same functionality available elsewhere,
> > or just that this is another way or doing it? I
> > would certainly think it would be advisable to
> > either have all your toolbar buttons (in a given
> > app or window) keyboard navigable or else none
> > of them...
> Say to do it when there is no other way to access
> the functionality, such as when there is no

OK.

> > Personally, I don't know why we can't just make
> > all toolbars keyboard navigable by default,
> > consistent with the way Microsoft Office (and
> > some other applications) do it. Is there a good
> > reason why this isn't the case?
> Mostly that no one has done it. We probably should
> do it. Anyone know if Vista apps do this by default?

I don't think so, but I can try to check later.


> >> -> The problem isn't just if the current item
> >> becomes disabled, hidden or destroyed. It could be
> >> any ancestor of the focus.
> >
> > Noted.
> Where was that noted?

Nowhere it seems. :) I'll try to get it in for real in the next
revision.


> > Testing on the "View->Character Encoding->Customize List..."
> > dialog results in the following: the "Move up" or
> > "Move down" buttons retains the focus indicator
> > even after being disabled. Tabbing moves normally
> > from there to the next element in the tab order.
> I think we have special code in that dialog for
> the focus issue.

I'd have to make up another test case to see the default behavior then,
but I'd guess it would just act crazy like the destruction case.

> > However, some earlier testing we did reveals
> > some much crazier behaviour when the focus element
> > is actually destroyed instead of merely being disabled,
> > in the which case the focus either started over at
> > the beginning of the dialog or jumped ahead two
> > positions in the tab order instead of one.
> Okay. Sounds like something we should improve in
> XUL (or actually everywhere in Mozilla more generally)

Probably. Does anyone know if there is any sort of standard for how
this works in other development frameworks? The same issue would exist
in html, Java, and native apps for any platform. I'd be interested in
knowing how (or if) they solved it.


> >> Form labels:
> >> -> I believe XUL, like HTML, allows the author to
> >> use the <label> element as a parent to both the
> >> label text and the form control. THere are a
> >> number of valid different ways to use it, which
> >> should be shown here in the code sample as correct.
> >> In the privacy panel image there is a prompt "[ ]
> >> Remember visited pages for the last ____ days"
> > I wasn't able to get this to work, but maybe I was
> > coding it wrong. If anyone can verify that it is
> > indeed possible, let me know and I'll put it in.
> I'm not sure if it is valid, actually. We need to
> check around.

I'm going to assume that it isn't (unless someone proves me wrong).
It's not listed on XulPlanet and didn't work when I tried it.


> >> -> The only way to deal with that is via
> >> aaa:labelledby. So, while I don't think you need
> >> to deal with ARIA much, I think this is one case
> >> where you need to show the technique. One other
> >> place is for aaa:describedby. Any floating static
> >> text descriptions should be tied to a form control
> >> or container element. Alternatively you can also
> >> now use <description control="[id]"> similar to
> >> the <label> element.
> >
> > I would be disappointed if we had to resort to
> > this, because like it amounts to telling people
> > they have to learn a completely different language
> > in order to make XUL accessible, whereas we told
> > them before that XUL had accessibility features
> > built-in. I also think that's where you'd end up
> > scaring off people and maybe doing more harm then
> > good. It's too bad we couldn't add a XUL widget or
> > attribute that would encapsulate the aaa stuff over
> > in XBL and make it easier for end users to use those
> > features.
> >
> > However, I'm certainly not in charge here, so if
> > the general consensus is that aaa: needs to be in
> > the guidelines, then somebody please point me to
> > some documentation where I can learn the aaa: stuff
> > so I can write about it.
> We really only need it for labelledby. I want to
> put it in, although the testing tool doesn't need
> to test for it. People are coming to this document
> to solve problems, and to get info. They won't
> want us to remove things just because it's a
> solution that's not pure XUL (we do mention HTML
> after all, and part of the power of this platform
> is to mix markup technologies).

OK. I'll add that to the TODO list.


> Also, please put <description control="[id]"> in
> there.  That's pure XUL and very useful. It means
> the description will get read aloud as the user
> tabs to something.

and that.

> >> Color:
> >> -> I think system colors can be used via CSS. See
> >> http://www.w3.org/TR/REC-CSS2/ui.html#system-colors
> >> -> Some of those items work. There are also some
> >> -moz color values. I'm not totally sure where they
> >> fit in.
> >
> > True, but I believe they are deprecated because
> > looking native takes more than just matching
> > colors these days. If it is correct that widgets
> > look native by default (somebody correct me if
> > this isn't the case), then I wouldn't think we
> > would need to discuss how to do it manually.
> Are you sure they're deprecated? If they aren't it
> might be least useful to mention them and point to
> a doc which contains them. People are always
> getting creative in the development of custom
> widgets and I would think that those hardcoded
> colors are useful in some situations.

Listed as deprecated at
http://www.w3.org/TR/CSS21/ui.html#system-colors because they are
superseded by http://www.w3.org/TR/css3-ui/#system .

I don't think we have full (or any?) support for the system stuff yet,
but there is a way to get native looking controls (via a -moz css
attribute I think). However, that probably wouldn't help much for
custom widgets, so we could mention system colors briefly for that
case.


> >> Emphasizing text:
> It still needs to be removed from the quick
> reference tables up top.

OK.


> >> Flexible sizing:
> >> "Some of the same functionality is found in CSS,
> >> but should be avoided"
> >> -> Not clear why it should be avoided
> >
> > Because CSS positioning sucks. What this is
> > trying to say is, XUL has a flexible box model
> > that is perfect for laying out controls, and
> > that even though it might work some of the
> > time, one shouldn't try to use css
> > position: and float: etc to layout a XUL
> > app.  hbox, vbox, grid, stack, deck, etc should
> > provide all the positioning you'd ever need.
> Okay, can you say "can be found in CSS
> positioning". At first I thought it meant the flex
> attributes etc. could be used in CSS.

OK.


> >> Testing display:
> >> -> I think it's useful to explain more details on
> >> how to do this on various platforms. The old
> >> guidelines say "Ensure compatibility with system
> >> themes, such as the high contrast theme on Windows
> >> (available via Left-alt + Left-shift +
> >> Printscreen)." I don't think we should remove that.
> >
> > If anyone knows an equivalent thing for linux or
> > mac, let me know and we can list them all. Otherwise,
> > I'll just put the windows example back in the way
> > it used to be.
> Just put that one in for now. The Gnome one can be
> simply done through the Gnome themes. There's no
> shortcut. Don't know about Mac.

Already done I believe.


> >> Alerts:
> >> Need to differentiate between alerts inside the
> >> current window and alert dialogs (which have their
> >> own window).
> >
> > Are we really going to have alerts inside the window
> > commonly? Shane was pretty convinced that we had to
> > talk about notificationbox here, but as I see it
> > notificationbox is really only useful on a browser
> > element, so it's not something 99% of all XUL
> > developers will ever need to worry about.
> It looks like you already mention both. Just make
> sure you say "alert dialog" whenever you mean an
> alert with its own window.

OK. I'll try to check all uses of the word "alert" and see what they're
supposed to be referring to.


> "Avoid moving interactive elements around. "
> -> Might want to make that a little clearer.
> Perhaps break that paragraph up so you can explain
> each item better.

I kind of made that issue up, but do think it's important sometimes
(because I have seen people break it and it does cause problems). I'll
try to make it clearer, but I can also get rid of it completely if you
want.

Aaron

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

Re: Revision of XUL accessibility guidelines

Steve Lee-3
> We can do that. Any suggestions for how to explain it quickly in a way
> that everyone will know what we're talking about?

How about:

Context Menu - a popup menu that offers a selection of actions
available for a particular item, object or 'context' on the display.
Often invoked with a click of the right mouse button.

Wikipedia is rather long winded http://en.wikipedia.org/wiki/Context_menu ;-^

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

Re: Revision of XUL accessibility guidelines

Tom Brunet
In reply to this post by Aaron Leventhal-3
I'll try to take a closer look at the rest of this later, but a quick
comment:

>> Personally, I don't know why we can't just make
>> all toolbars keyboard navigable by default,
>> consistent with the way Microsoft Office (and
>> some other applications) do it. Is there a good
>> reason why this isn't the case?
> Mostly that no one has done it. We probably should do it. Anyone know if
> Vista apps do this by default?

IE7 seems to make half of its toolbar navigable - some buttons are in
the tab order, but not all of them.  The only argument that I've heard
against the toolbar being keyboard navigable is that it adds too much
static information to the tab order.  The HTML equivalent would be the
navigation menus where it is good practice to provide skip links.

Since there's really no equivalent to a skip link in chrome, and toolbar
button function tends to be in the menu anyway, the trend seems to be to
pull everything out of the tab order.

I did see one application where the toolbar was part of the F6 order,
and therefore you could skip past the toolbar by pressing F6.  I don't
know that you could do this with Firefox since the URL bar is already in
the F6 order and tends to be in the middle of the toolbar.

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

Re: Revision of XUL accessibility guidelines

Aaron Andersen-2
In reply to this post by Shane Anderson
The current version of the guidelines is now at
http://developer.mozilla.org/en/docs/XUL_accessibility_guidelines

There were a few major changes and a few minor ones since the previous
version. First, I moved the whole thing over to DevMo, which took more
work than I thought it would but was a lot of fun. The guidelines can
now be (and I think are now ready to be) edited by the community at
large.

* Rewrote the introduction (I really hated the old one).

* Redid some of the screenshot examples and took out some of the
others.

* Moved the checklist to the bottom, cleaned up the styles, and updated
the content.

* Added a part about aaa:labelledby to the section on form labels.

* Some other minor things here and there according to the comments I
got from Aaron Leventhal and others.


Overall I think it's starting to look pretty good. I'm probably going
to shift gears now and put some major work into the XUL Accessibility
Evaluation Tool, but feedback on this (and that, once I get it up) is
still welcome.

Aaron

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

Re: Revision of XUL accessibility guidelines

Jonathan Chetwynd
Aaron,

excellent news.

Is it a limitation of the technology that tables are being used for  
layout?
div seem in short supply ~:"

cheers

Jonathan Chetwynd



On 12 Jan 2007, at 22:13, Aaron Andersen wrote:

The current version of the guidelines is now at
http://developer.mozilla.org/en/docs/XUL_accessibility_guidelines

There were a few major changes and a few minor ones since the previous
version. First, I moved the whole thing over to DevMo, which took more
work than I thought it would but was a lot of fun. The guidelines can
now be (and I think are now ready to be) edited by the community at
large.

* Rewrote the introduction (I really hated the old one).

* Redid some of the screenshot examples and took out some of the
others.

* Moved the checklist to the bottom, cleaned up the styles, and updated
the content.

* Added a part about aaa:labelledby to the section on form labels.

* Some other minor things here and there according to the comments I
got from Aaron Leventhal and others.


Overall I think it's starting to look pretty good. I'm probably going
to shift gears now and put some major work into the XUL Accessibility
Evaluation Tool, but feedback on this (and that, once I get it up) is
still welcome.

Aaron

_______________________________________________
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
|

Seeking reviewers [was Re: Revision of XUL accessibility guidelines]

Aaron Leventhal-3
In reply to this post by Aaron Andersen-2
Hello, if people wouldn't mind giving the new XUL
accessibility guidelines a glance/review, it would
be helpful to get feedback.

Cross-posted, with followup-to set to
mozilla.dev.accessibility.

- Aaron

Aaron Andersen wrote:

> The current version of the guidelines is now at
> http://developer.mozilla.org/en/docs/XUL_accessibility_guidelines
>
> There were a few major changes and a few minor ones since the previous
> version. First, I moved the whole thing over to DevMo, which took more
> work than I thought it would but was a lot of fun. The guidelines can
> now be (and I think are now ready to be) edited by the community at
> large.
>
> * Rewrote the introduction (I really hated the old one).
>
> * Redid some of the screenshot examples and took out some of the
> others.
>
> * Moved the checklist to the bottom, cleaned up the styles, and updated
> the content.
>
> * Added a part about aaa:labelledby to the section on form labels.
>
> * Some other minor things here and there according to the comments I
> got from Aaron Leventhal and others.
>
>
> Overall I think it's starting to look pretty good. I'm probably going
> to shift gears now and put some major work into the XUL Accessibility
> Evaluation Tool, but feedback on this (and that, once I get it up) is
> still welcome.
>
> Aaron
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Seeking reviewers [was Re: Revision of XUL accessibility guidelines]

Neil-4
Aaron Leventhal wrote:

> Hello, if people wouldn't mind giving the new XUL accessibility
> guidelines a glance/review, it would be helpful to get feedback.

Two things I happened to spot:

a. Toolbarbuttons can be given accesskeys even though they're not
typically focusable.
b. With care, jumping focus can be useful. In the phone number case,
only jump forward when the 4th digit is pressed (and enter that 4th
digit into the second field). Also don't forget to jump back and delete
the last character in the previous field when backspacing in an empty field.

--
Warning: May contain traces of nuts.
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Revision of XUL accessibility guidelines

Aaron Leventhal-3
In reply to this post by Aaron Andersen-2
Aaron Anderson -- I have to agree with Jonathan.
Since we are talking about accessibility markup
here we should provide a good example in the HTML
as well.

We really ought to address the tables in your wiki
markup which are really being used for layout. For
example, the single column tables which can just
be done with a heading followed by a list.

- Aaron

Jonathan Chetwynd wrote:

> Aaron,
>
> excellent news.
>
> Is it a limitation of the technology that tables are being used for layout?
> div seem in short supply ~:"
>
> cheers
>
> Jonathan Chetwynd
>
>
>
> On 12 Jan 2007, at 22:13, Aaron Andersen wrote:
>
> The current version of the guidelines is now at
> http://developer.mozilla.org/en/docs/XUL_accessibility_guidelines
>
> There were a few major changes and a few minor ones since the previous
> version. First, I moved the whole thing over to DevMo, which took more
> work than I thought it would but was a lot of fun. The guidelines can
> now be (and I think are now ready to be) edited by the community at
> large.
>
> * Rewrote the introduction (I really hated the old one).
>
> * Redid some of the screenshot examples and took out some of the
> others.
>
> * Moved the checklist to the bottom, cleaned up the styles, and updated
> the content.
>
> * Added a part about aaa:labelledby to the section on form labels.
>
> * Some other minor things here and there according to the comments I
> got from Aaron Leventhal and others.
>
>
> Overall I think it's starting to look pretty good. I'm probably going
> to shift gears now and put some major work into the XUL Accessibility
> Evaluation Tool, but feedback on this (and that, once I get it up) is
> still welcome.
>
> Aaron
>
> _______________________________________________
> 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: Revision of XUL accessibility guidelines

Mark Pilgrim
In reply to this post by Tom Brunet
On 1/12/07, Tom Brunet <[hidden email]> wrote:

> I'll try to take a closer look at the rest of this later, but a quick
> comment:
>
> >> Personally, I don't know why we can't just make
> >> all toolbars keyboard navigable by default,
> >> consistent with the way Microsoft Office (and
> >> some other applications) do it. Is there a good
> >> reason why this isn't the case?
> > Mostly that no one has done it. We probably should do it. Anyone know if
> > Vista apps do this by default?
>
> IE7 seems to make half of its toolbar navigable - some buttons are in
> the tab order, but not all of them.  The only argument that I've heard
> against the toolbar being keyboard navigable is that it adds too much
> static information to the tab order.  The HTML equivalent would be the
> navigation menus where it is good practice to provide skip links.

I did a survey of some applications/controls here:
https://bugzilla.mozilla.org/show_bug.cgi?id=287743#c8

The results are all over the map.  I argued (and lost) with MozCo
developers that all toolbar buttons should be in the tab order by
default.  There were some edge cases that were not handled by the
current infrastructure (if you tab to a button and press it, and it
becomes disabled, where does focus go?) but basically they are opposed
to the idea for mostly historical reasons.  ("We've always done it
this way.")  Perhaps someone else can convince them someday.

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

Re: Revision of XUL accessibility guidelines

Mark Pilgrim
In reply to this post by Aaron Andersen-2
On 12 Jan 2007 14:13:01 -0800, Aaron Andersen <[hidden email]> wrote:
> The current version of the guidelines is now at
> http://developer.mozilla.org/en/docs/XUL_accessibility_guidelines

I'm reviewing this version right now, but here's an initial question:
why are the screenshots showing the Mac version of Firefox when Mac OS
X is not one of our supported accessible platforms?

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

Re: Revision of XUL accessibility guidelines

Mark Pilgrim
In reply to this post by Aaron Andersen-2
On 12 Jan 2007 14:13:01 -0800, Aaron Andersen <[hidden email]> wrote:
> The current version of the guidelines is now at
> http://developer.mozilla.org/en/docs/XUL_accessibility_guidelines

I made some wording changes to the Toolbarbuttons section.  Don't
recommend class="tabbable" since IIRC that is Firefox-specific and
does not work in other XUL-based applications.  The CSS style rule
works everywhere.

The section on Scrolling is generally incoherent.  Can the
arrowscrollbox be made accessible by controlling it from another
widget?  Are those overflow CSS rules dangerous in all cases, just
some, or what?  (I honestly don't know, and afterreading the
guidelines I am even more confused.)

The section on Maintaining focus should probably be split up, since
moving-focus-as-a-control-goes-inactive and
not-auto-changing-focus-on-data-validation are two distinct use cases.
 Or perhaps the second example should go first, and then mention the
soon-to-be-inactive use case as the exception that proves the rule.

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

Re: Revision of XUL accessibility guidelines

Mark Pilgrim
In reply to this post by Aaron Andersen-2
On 12 Jan 2007 14:13:01 -0800, Aaron Andersen <[hidden email]> wrote:
> The current version of the guidelines is now at
> http://developer.mozilla.org/en/docs/XUL_accessibility_guidelines

The section on Testing keyboard access implies that it is "simply" a
matter of  unplugging your mouse, then goes on to say you should
ensure that shortcuts do not interfere with assistive technologies.
This feels like a bait-and-switch: "Look, it's easy!  Oh, by the way,
buy these $1500 applications too."  Perhaps we could just link to the
documentation on JAWS and Window Eyes default shortcuts?

Here's Window-Eyes:
http://www.gwmicro.com/Window-Eyes/Manual/HTML/index.html?appendix_a_1.htm

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

Re: Revision of XUL accessibility guidelines

Aaron Leventhal-3
In reply to this post by Aaron Andersen-2
Mozilla automatically puts anything that's made
scrollable via CSS into the tab order. We
considered it a section 508 issue, to be able to
scroll with the arrow keys and make everything
visible.

- Aaron

Mark Pilgrim wrote:

> On 12 Jan 2007 14:13:01 -0800, Aaron Andersen <[hidden email]> wrote:
>> The current version of the guidelines is now at
>> http://developer.mozilla.org/en/docs/XUL_accessibility_guidelines
>
> I made some wording changes to the Toolbarbuttons section.  Don't
> recommend class="tabbable" since IIRC that is Firefox-specific and
> does not work in other XUL-based applications.  The CSS style rule
> works everywhere.
>
> The section on Scrolling is generally incoherent.  Can the
> arrowscrollbox be made accessible by controlling it from another
> widget?  Are those overflow CSS rules dangerous in all cases, just
> some, or what?  (I honestly don't know, and afterreading the
> guidelines I am even more confused.)
>
> The section on Maintaining focus should probably be split up, since
> moving-focus-as-a-control-goes-inactive and
> not-auto-changing-focus-on-data-validation are two distinct use cases.
> Or perhaps the second example should go first, and then mention the
> soon-to-be-inactive use case as the exception that proves the rule.
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Revision of XUL accessibility guidelines

Mark Pilgrim
In reply to this post by Tom Brunet
On 1/12/07, Tom Brunet <[hidden email]> wrote:
> I did see one application where the toolbar was part of the F6 order,
> and therefore you could skip past the toolbar by pressing F6.  I don't
> know that you could do this with Firefox since the URL bar is already in
> the F6 order and tends to be in the middle of the toolbar.

Yeah, sorta, well, actually, no.  See, for example,
https://bugzilla.mozilla.org/show_bug.cgi?id=249735 and in particular
my comments here:
https://bugzilla.mozilla.org/show_bug.cgi?id=249735#c24

F6 is only accidentally an accessibility feature, and even so, it
doesn't work very well.  In the default case, it seems like it's a
useful accessibility feature, but explaining what it really does in
the general case requires some knowledge of Firefox internals.  I'd be
quite happy if we removed it, but we all know that's never going to
happen.

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

Re: Revision of XUL accessibility guidelines

Aaron Andersen-2
In reply to this post by Aaron Leventhal-3

Aaron Leventhal wrote:
> Aaron Anderson -- I have to agree with Jonathan.
> Since we are talking about accessibility markup
> here we should provide a good example in the HTML
> as well.
>
> We really ought to address the tables in your wiki
> markup which are really being used for layout. For
> example, the single column tables which can just
> be done with a heading followed by a list.

The only tables in my layout are the checklist at the bottom and the
"Learn More" tables throughout. The checklist obviously needs to be a
table, so I hope nobody's complaining about that. As far as the "Learn
More" tables go, the mere fact that some of them only have one column
does not mean they are being used for layout purposes. I see them as
legitimate tables, correctly marked up with captions and headers. The
ones with only a single column may have more columns in the future, but
even if they never do I still don't think that makes the markup
invalid, and I think it's important to be consistent and have all of
them use the same structure.

That having been said, it's a wiki, so if someone has a much better
idea, go for it, or if I'm the only one who even likes the "Learn More"
tables, somebody feel free to delete them.

Oh, and I agree that the lists of links should be marked up as a real
list, I just gave up trying to override the default list styles in wiki
code because I didn't want bullets or margins on them. If that's a big
issue I can certainly try again to get them to look good as lists.

Aaron

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

Re: Revision of XUL accessibility guidelines

Aaron Andersen-2
In reply to this post by Aaron Andersen-2

Mark Pilgrim wrote:

> On 12 Jan 2007 14:13:01 -0800, Aaron Andersen <[hidden email]> wrote:
> > The current version of the guidelines is now at
> > http://developer.mozilla.org/en/docs/XUL_accessibility_guidelines
>
> The section on Testing keyboard access implies that it is "simply" a
> matter of  unplugging your mouse, then goes on to say you should
> ensure that shortcuts do not interfere with assistive technologies.
> This feels like a bait-and-switch: "Look, it's easy!  Oh, by the way,
> buy these $1500 applications too."  Perhaps we could just link to the
> documentation on JAWS and Window Eyes default shortcuts?
>
> Here's Window-Eyes:
> http://www.gwmicro.com/Window-Eyes/Manual/HTML/index.html?appendix_a_1.htm
>
> --
> Cheers,
> -Mark

That sentence was supposed to have been deleted, per a previous
discussion with Aaron Leventhal in which it was agreed that it's better
not to bring that issue up at all (for the reasons you mentioned).

Aaron

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