W3C home > Mailing lists > Public > public-wai-eo-badtf@w3.org > September 2010

Re: a little bit of script testing?

From: Shadi Abou-Zahra <shadi@w3.org>
Date: Mon, 06 Sep 2010 11:38:04 +0200
Message-ID: <4C84B67C.5010208@w3.org>
To: Wilco Fiers <w.fiers@accessibility.nl>
CC: Wilco Fiers <wfiers@bartimeus.nl>, BAD TF <public-wai-eo-badtf@w3.org>
Hi Wilco,

Thank you for your feedback! A couple of responses:


On 06.09.2010 11:12, Wilco Fiers wrote:
> Hello Shadi,
>
> I suppose there are a few ways you could look at it. I tend to go by which element is most like what you want to do. Links point you to resources, so when I made the lightboxes with the annotations I used links because it points the user to a part of the content. For making changes in content such as expanding or collapsing I think buttons are the most elegant, because buttons are used for requesting a change, not some specific resource. Then again in things such as FAQs where you might use the question to expand the answer, that is already a lot more like a link then a button.

Absolutely. Which is why we are doing some informal testing with users 
(EOWG participants for now), to understand some of those preferences.


> Personally I wouldn't use a checkbox (or it's role) because checkboxes are for inserting user information, not changing context. As a purely HTML component it doesn't do anything until we press the submit button. I would suggest disabling the button which can't be used. In the way you've done it you can't tell the state of the top buttons without CSS.

I agree with the disabling, I need to implement that. However, what 
would you use for a toggle? An activated/deactivated button?


> And here's the nitpicky point, technically when your paragraphs are collapsed, your heading shouldn't be headings anymore. For something to be a heading it requires some kind of content to come ofter it to which it can be a heading. Headings are only headings in relationship to content. If you remove the content, you should probably be removing the header markup too. Now I know that's quite fiddly and the reason why nobody does it. But it's something worth considering. The best solution to this I think is to use the default state - whatever it starts off as - to be correct, and to allow for semantic errors as the user interacts with the page. In your example that would mean not using the headers, but to use a list instead.

This is a good point. Actually, some users are having troubles with 
buttons being part of the headings too. I'll think about this.


> Hope this helps. Btw why did you use tabindex on the buttons? I can't really think of any need for them, could you clarify?

I was hoping it could help fix some of the buffer refresh issues in some 
of the screen readers but it does not seem to work either.


Thank you for your feedback, I'll work on another attempt...

Best,
   Shadi


> Regards,
>
> Wilco
> ________________________________________
> Van: Shadi Abou-Zahra [shadi@w3.org]
> Verzonden: zondag 5 september 2010 15:49
> Aan: Wilco Fiers
> CC: BAD TF
> Onderwerp: Fwd: a little bit of script testing?
>
> Hi Wilco, BAD TF,
>
> For your information, I am currently working on an expand/collapse
> functionality similar to the one we've implemented for BAD [1].
>
> Some of the comments we received relate to use of links rather than
> buttons for the functionality. In particular, some argue that the
> expand/collapse all should become a toggle rather than be a link.
>
> Below you can find a test page in which I'm looking into using the
> button elements with WAI-ARIA instead [2]. Any comments are welcome.
>
> [1]<http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/2009/>
> [2]<http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/2009/test.html>
>
> Best,
>     Shadi
>
>
> -------- Original Message --------
> Subject: a little bit of script testing?
> Date: Sun, 05 Sep 2010 15:41:54 +0200
> From: Shadi Abou-Zahra<shadi@w3.org>
>
> Hi folks,
>
> Ref:<http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/2009/test.html>
>
> Thank you for your feedback on the expand/collapse script so far. I'm
> looking at some ways to improve its accessibility and would appreciate
> if any of you can spare some additional time to do more testing.
>
> The main changes are:
>    - use of the button element rather than links, for all functions
>    - use of WAI-ARIA roles and states to communicate what is happening
>    - more descriptive button names to better communicate their purpose
>
>
> Some known issues are:
>    - the expand/collapse button still appears at the beginning of the
> heading text rather than at the end. It is not a trivial task to get
> this to happen across some particular browsers. Any suggestions or
> tipps/tricks are highly welcome.
>    - the visual styling will be looked at in more detail, especially to
> make it more consistent across different browsers (buttons are quite
> tricky in some browsers). Liam was suggesting the "silk" icons from
> Famfamfam<http://www.famfamfam.com/>.
>
>
> What I'm particularly looking for is:
>    - how well does this functionality work with different browsers and
> assistive technology (note that screen readers read aloud the button
> names, types, and states differently, sometimes even when you use the
> same screen reader but with different browsers).
>    - how understandable and usable is the functionality, especially if
> you imagine that you are working with it for the first time.
>
>
> Any other comments or suggestions are welcome too.
>
> Many thanks,
>     Shadi
>
> --
> Shadi Abou-Zahra - http://www.w3.org/People/shadi/ |
>     WAI International Program Office Activity Lead   |
>    W3C Evaluation&  Repair Tools Working Group Chair |
>

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/ |
   WAI International Program Office Activity Lead   |
  W3C Evaluation & Repair Tools Working Group Chair |
Received on Monday, 6 September 2010 09:38:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 September 2010 09:38:35 GMT