- From: Detlev Fischer <detlev.fischer@testkreis.de>
- Date: Fri, 30 Jun 2017 12:03:43 +0200 (CEST)
- To: acampbell@nomensa.com
- Cc: w3c-wai-gl@w3.org, public-cognitive-a11y-tf@w3.org
Hi Alastair, yes, I eventually found that example but it does not seem usable in any real-world way - I was looking for something where we might ask users: "Try to find the place where you can buy clothes for children" (or similar) If you do that on this online clothes site, you can't go anywhere since there are no page stubs for the link destinations. Confusingly, activating the link takes you back to the initial design. Also, users probably won't know what "Personalise (Read JSON)" is supposed to do for them. If they do activate that link (prompted by a test facilitator, for example) they get a completely different design. There is no obvious way to get back to the prior state (it could appear to be a different page but the back button won't work). As to "More options / Less options": What I (others?) at first expected to be a toggle option between the initial first and the second view now presented (which has fewer options if you manage to remember what the page looked like first) turns out to incrementally add or remove navigation options. All this is kind of hard to understand and completely outside of what users would assume to be the main purpose of the site if it was to be used as a usability testbed for personalisation approaches. As to the potential alternative task of "Fill in and send the contact form", the form does not seem to benefit in any perceivable way from the ARIA coga-attributes (there is aria-function=submit on the submit but that seems to be redundant as it reiterates the type attribute of the input, and it "does" nothing). A form suitable for user testing should also even out a few things like using @placeholder for the message placeholder and submitting instead of unexpectedly opening users' e-mail client with the processed (technical-looking) results of the form. So to sum up, I don't think any meaningful user testing activity can be carried out based on this implementation. I also looked at the example pointed to by Christophe http://build.fluidproject.org/prefsEditors/demos/explorationTool/ and while this is closer to being usable, there are some odd choices like the default visibility of the GPII preferences editor and the icons that look like they should do something but don't the placement of "doesn't make sense" to reveal the menu for personalisation etc. But I stop nagging now. So I would really encourage anyone with time at hand to put together examples that are closer to things that can actually be tested with users (task-based testing). If such tests have taken place during the gestation of the aria for coga spec (which I hope), I wonder why the testbeds are not openly available for testing by other people. The fact that there is hardly anything that looks remotely useful makes me a bit suspicious. So, if there are more useful implementations to look at, I am very keen to learn about them! Best, Detlev -- Detlev Fischer testkreis c/o feld.wald.wiese Thedestr. 2, 22767 Hamburg Mobil +49 (0)157 57 57 57 45 Fax +49 (0)40 439 10 68-5 http://www.testkreis.de Beratung, Tests und Schulungen für barrierefreie Websites Alastair Campbell schrieb am 30.06.2017 09:56: > > Detlev wrote: > > > > Are there any implementations of the COGA Semantics to Enable Personalization that can be looked at / tried out and that would show the benefits of, four example, adding icons via coga-action or coga-destination? > > > > > The github repo for a demo is here: > > https://github.com/ayelet-seeman/coga.personalisation <https://github.com/ayelet-seeman/coga.personalisation> > > > > And I the live demo based on that is here: > > http://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html <http://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html> > > > > I grabbed some screenshots for an article for those that can see them: > > https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/#customisation <https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/#customisation> > > > > It is one thing to create a demo specifically for the purpose, but a better test would be to apply it to a real website, or even one page saved off from a website. The reason I put customisation/personalisation as the highest of the levels is the impact on the site: > > https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/#customisation <https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/#customisation> > > > > The links Lisa sent around using the product layered on top were generally applying changes at level 2 on my list (overriding author styles without impacting layout). Adding icons and adjusting the number of links in a nav is at level 4 because of the design and testing overhead. > > > > Cheers, > > > > -Alastair > >
Received on Friday, 30 June 2017 10:04:13 UTC