On Nov 13, 2009, at 11:00 AM, Vincent Massol wrote:
ok I wasn't aware of the .hidden class.
So do we still want a new .accessibility class or should we use
the .hidden one?
My take is that .accessibility is more semantic (which means we
don't need to add a comment wherever we use it for accessibiility
reasons) but OTOH it introduces a new class.
I'm still +1 to add it.
Sergiu isn't sure about .accessibility since there are existing
accessibility stuff already so I'll commit with .hidden for now till
we agree on how we want to manager accessbiility stuff in general.
Please let's continue this discussion. Waiting for Sergiu's proposal :)
Thanks
-Vincent
Thanks
-Vincent
On Nov 12, 2009, at 5:27 PM, Ecaterina Valica wrote:
> although we have a class called .hidden - it was until now used to
> hide:
> - accessibility elements, like action menu indicators
> - JS toggled elements
>
> We could have a separation for accessibility elements from the other
> layout/implementation hidden elements. This could be useful in case
> we want
> to transit some accessibility into the layout.
>
> or we could keep .hidden to do both.
>
> Jerome, .hidden did NOT disappeared from colibri.css.
>
> On Thu, Nov 12, 2009 at 17:13, Vincent Massol <vincent(a)massol.net>
> wrote:
>
>> Hi,
>>
>> While working on WCAG we've found that we need to hide some
>> content so
>> that it's not displayed visually but it's used by assistive devices
>> (such as a web browser reader).
>> For example for label texts in compact forms (where we put the label
>> inside the field -e.g. the search box).
>>
>> Another example are "skip content" and "got to top"
features.
>>
>> Thus I'd like to propose adding a new public CSS class called
>> "accessibility":
>>
>> .accessibility {
>> display: none
>> }
>>
>> We need a vote since it's public and would be used for example in
>> the
>> form located in Main.Spaces. This means that all skins (ours or
>> custom
>> skins done by users) must have it (or the label will be displayed).
>>
>> WDYT?
>>
>> Here's my +1
>>
>> Thanks
>> -Vincent
>>
>> PS: BTW this raises the question of public vs non public CSS
>> classes.
>> Do we have a list somewhere? If not shouldn't we have one to let
>> skin
>> authors know what class must absolutely exist and also to ensure we
>> don't use non public classes in document content or in templates
>> (non
>> skin templates)?