Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

proposed shared switch/checkbox/radio changes

17 views
Skip to first unread message

Eitan Isaacson

unread,
Sep 11, 2013, 6:07:25 PM9/11/13
to dev-...@lists.mozilla.org, Marco Zehe
Hi Gaia,

I am doing work to make Gaia more accessible to screen readers and I
have a proposed change to our shared
pack-switch/pack-checkbox/pack-radio classes. Basically, I want to use
the empty <span> as an actual text label as well as the styled state it
is now. My changes seem to be backward compatible with the current usage
throughout gaia, at least in ltr languages. You can see the changes here[1].

First of all the problem: In the settings app, we use these classes a
lot for different option toggles. Often, the label describing the
checkbox is separate from the actual checkbox, and is often an anchor
tag. Here is an example:

<li>
<label class="pack-switch">
<input name="ril.radio.disabled" class="uninit" type="checkbox">
<span></span>
</label>
<a class="menu-item" data-l10n-id="airplaneMode">Airplane Mode</a>
</li>

To clean this up for screen reader use, we need to use a lot of aria[2]
acrobatics. Both for changing roles, preserving checked/unchecked states
and associating the localized label with the control.

With the changes I propose, the same visual/functional outcome could be
done with this markup:

<li>
<label class="pack-switch">
<input name="ril.radio.disabled" class="uninit" type="checkbox">
<span class="menu-item" data-l10n-id="airplaneMode">Airplane Mode</span>
</label>
</li>

>From a pure line count perspective, this is not a huge deal. But from a
screen reader perspective it is, since the entire composite widget is
contained by the label.

This seems to be an inter-app change, so I thought I would post here
first to see what folks thought.

1. https://github.com/eeejay/gaia/compare/switch-do-over
2. http://www.w3.org/TR/wai-aria/

Julien Wajsberg

unread,
Sep 12, 2013, 4:50:33 AM9/12/13
to Eitan Isaacson, dev-...@lists.mozilla.org, Marco Zehe
YES !! :)

I raised this a long while ago when I reviewed some patch in the system
app, and was answered "yeah, it's the bulding blocks so we can't really
change this now".

I want this. Thanks !
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia


signature.asc

ARNAU MARCH CASTILLO

unread,
Sep 12, 2013, 5:13:11 AM9/12/13
to Julien Wajsberg, <dev-gaia@lists.mozilla.org>, Eitan Isaacson, Marco Zehe
I can always change the BB to improve them!
I´ll make sure this gets fixed.
Arnau

On Sep 12, 2013, at 10:50 AM, Julien Wajsberg <jwaj...@mozilla.com>
wrote:
________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

ARNAU MARCH CASTILLO

unread,
Sep 12, 2013, 5:16:22 AM9/12/13
to Julien Wajsberg, <dev-gaia@lists.mozilla.org>, Eitan Isaacson, Marco Zehe
BTW Eitan,

I you have more issues regarding accessibility in Building Blocks, please let me know.
We are refactoring BB and it's a good time to make these changes.

Marco Zehe

unread,
Sep 12, 2013, 7:24:52 AM9/12/13
to ARNAU MARCH CASTILLO, Julien Wajsberg, <dev-gaia@lists.mozilla.org>, Eitan Isaacson
Hi Arnau, Julien,

there are a few issues I saw while glancing over the building blocks and also the Gaia code, that have common patterns:

1. Tabs in tab lists are not marked up correctly. They should look something similar to what I blogged here: http://www.marcozehe.de/2013/02/02/advanced-aria-tip-1-tabs-in-web-apps/

2. In the phone app, and other places, the order of elements is not logical. For example the dial pad, when going through the DOM or accessibility tree, should have the numbers 1, 2, 3 in order, followed by the next row. Instead, the numbers are arranged vertically, so the screen reader sees 1, 4, 7, * etc.

3. Dialogs have a common pattern of not being marked up correctly, too, for screen readers. An article describing how ARIA dialogs (there is no native HTML dialog element or widget type) should be marked up: http://juicystudio.com/article/custom-built_dialogs.php

4. If a widget acts like a button, the button element with the according type should be used. So instead of span role="button" or the like, a true html:button element should be used. In other cases, html:a with a href to make it a true link might be more appropriate.

Please, always contact Eitan or myself if you have questions about specific markup. Also, a meta bug we have to keep track of Gaia accessibility bugs is here: https://bugzilla.mozilla.org/show_bug.cgi?id=893789.

Marco

Vivien Nicolas

unread,
Sep 12, 2013, 7:49:19 PM9/12/13
to dev-...@lists.mozilla.org
Hey,

Just want to let you know that we are thinking about reusable components
more and more.

There is no final decision on anything yet, or even a real schedule
behind it since it depends on some platform feature like Web Components.
I have been told that it should be ready in a few months so right now
this is more about building a plan around it, but in any case we would
really enjoy to have the accessibility team on board with us when it
will start.

The basic plan I have in mind right now is:

Building blocks are the basic layout/theming parts. Those already exists
in Gaia as a convention of <tag>s with some css classes.

Those building blocks, for the most part, does not have any associated
logic yet.

Then when Web Components will let us add some logic to those building
blocks. I can imagine a first step where we will create components just
by wrapping the existing building blocks layout directly and use the
define component to replace it and fix the applications when they tried
to access directly and element that is now inside the component.

This will give us a good understanding of the first methods/properties
we should expose on those components.

When this phase is done we should be able to change the layout of a
particular web component afterward.
This is likely the phase were the performance team and the accessibility
team should work together to define an efficient and meaningful layout.

Here is the dumb plan I have in mind right now. Comments are welcome
(but maybe on a separate thead to not pollute this one).

Eitan Isaacson

unread,
Sep 13, 2013, 5:54:22 PM9/13/13
to ARNAU MARCH CASTILLO, Julien Wajsberg, <dev-gaia@lists.mozilla.org>, Marco Zehe
Thanks Arnau.

This is now being tracked in bug 914892

https://bugzilla.mozilla.org/show_bug.cgi?id=914892

On 09/12/2013 02:16 AM, ARNAU MARCH CASTILLO wrote:
> BTW Eitan,
>
> I you have more issues regarding accessibility in Building Blocks, please let me know.
> We are refactoring BB and it's a good time to make these changes.
>
> Arnau
>
> On Sep 12, 2013, at 10:50 AM, Julien Wajsberg <jwaj...@mozilla.com>
> wrote:
>
>> YES !! :)
>>
>> I raised this a long while ago when I reviewed some patch in the system
>> app, and was answered "yeah, it's the bulding blocks so we can't really
>> change this now".
>>
>> I want this. Thanks !
>>
0 new messages