incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Buhler <davidbuh...@gmail.com>
Subject Re: Pushing Flex components thorough the GPU
Date Tue, 24 Jan 2012 21:03:36 GMT
Hi Roland,

The inability to scroll through a list would not always be a show-stopper
for an accessible user.

The Section 508 Requirements state (and I'm paraphrasing here):

-users with disabilities need to be able to access the same information
(contextually) as a sighted user.

Disabilities includes people who are blind, color-blind, hard of hearing,
deaf, are missing a limb, have cognitive disabilities, etc.

Tab Indexing is not too important, since Flash Player takes care of tab
order.  Being able to precisely position controls for Tab Order is
important.
Being able to disable tabbing to 'secondary' controls is important.
Being able to set focus with specific keys (tab) and open controls like
combo-boxes is important (Space bar?).

With regard to ItemRenderers, I would argue that no developer would present
to a blind user, controls and data, within a grid. It's difficult to keep a
sense of state, difficult to provide enough context about the visual
hierarchy, difficult to provide enough context about relationships (one
column changes the value of another), and it's difficult to 'exit' the grid
when the grid has a lot of content (tab, tab, tab, tab, tab, ...quit).

Point is, I don't think Accessibility has to (or can) apply to every
control. Especially the DataGrid (and more importantly, the Advanced
DataGrid).

If I remember right, not all Adobe Controls were accessible in 4.1. I am
not sure of the current state of accessibility in the Spark Controls
(although Adobe did have a list of accessible controls).

I found the best implementation for accessibility to be this: Within most
Forms (and this would apply to ItemRenderers), I would show a tab-enabled
LinkButton if the user had a screen-reader (JAWS) running. This allowed me
to include additional context (such as repeat of the question preface at
the top of a Form for a specific FormItem). Tabbing to this control would
also let the user know what their options were, what their current
control's selection was, what validation errors they might have, etc.

The bigger issues come when the focus is reset on a Form when the Form
changes in size and the focus is set elsewhere. Impaired users can't lose a
sense of 'state'. A good 'container' would force "Focus" when a screen is
shown.

A good Alert / Framework would record the last control with focus, and set
the control back on the last control with Focus when the Alert shuts down.

Impaired users who use a screen-reader will have to listen to Adobe's
default content in the HTML page while they wait for the Flash Player to
make a JavaScript call to set the focus on the SWF when the SWF is done
loading (provided the developer implements this logic). An accessibility
flag would ideally remove this copy from the build.

Most lists need to provide ccess to the underlying label for visually
impaired users (combo-boxes, lists). The DataGrid may not be one of those
list-types for the reasons mentioned above.

An ItemRenderer (in a simple list) needs to allow for the appropriate
placement of controls to control the tab-order, and I would argue you need
an additional control that displays when the user is using a screen-reader
within the ItemRenderer that can have content applied at run-time when the
control gains focus. Other controls need the ability to be tab-disabled
(and bound to a singleton's model property) so they do not repeat the same
content as the more accessible friendly copy (for example, a label or text
that better suited for a user without a screen-reader).

A good list would provide a hot-key to exit the list's focus.

A good Flex Framework for accessibility would provide a list of hot-keys
when the application first starts-up, to tell the user how to navigate
using the keyboard. This could be a simple button or Alert window, that,
when sensing the user has JAWS running on IE, opens a Window that takes
focus and shares this content.

An ItemRenderer for colorblind users needs to provide shapes in addition to
colors to be used as a visual indicator. A control marked for accessibility
(accessible=true) should ideally check for these common types of unmet
conditions (for each color provided, does an image exist as well).

Validation messages need to always indicate the control by a user-friendly
name (the State of Residence is not selected) instead of "State is not
selected".  The error messages need to be VERY granular (The State of
residence is invalid would not be accessible since the user does not know
what is wrong with the control).

Some words can't be pronounced well enough by a Screen-Reader ("invalid" is
an example), so the developer needs to ensure controls that provide enough
context Still provide an alternative approach to sharing information. A
List, for example, should provide a label alternative for users using a
screen-reader.

The ability to resize text at run-time is also a critical piece of
accessibility that should be part of any accessibility implementation
(or accessibility framework). Text-Resizing is important to low-sighted
users.

Regards,
BUHLER

On Tue, Jan 24, 2012 at 11:38 AM, Roland Zwaga <roland@stackandheap.com>wrote:

> On 24 January 2012 17:29, David Buhler <davidbuhler@gmail.com> wrote:
>
> > I built a Flex website for the Federal government that was fully
> accessible
> > (PCIP.gov). I did a demo for Adobe of the Accessibility capabilities. I'm
> > glad to help with answering any accessibility questions.
> >
>
> Hey David,
>
> thanks for chiming in :) As you read the proposed usage of Stage3D in, for
> example, item renderers,
> what would be the accessibility concerns, in your opinion?
> From what I would gather, the main things that ought to work would be to
> tab through the controls,
> and through list items, for example. That would already complicate things
> since the Stage3D objects
> should seamlessly fit into the tab order of the DisplayObjects.
> I'm still not sure what exactly the accessibility limitations of Stage3D
> are, but I'm guessing tab focus will
> be one of them. So, not being able to tab/scroll through a List's itemslist
> would already be deemed
> unacceptable behavior. Am I right?
>
> Roland
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message