W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

Re: Do we like this better? - was way to move forward with plain language

From: Gregg C Vanderheiden <greggvan@umd.edu>
Date: Mon, 22 May 2017 09:37:32 -0400
Cc: Alastair Campbell <acampbell@nomensa.com>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>, public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
Message-Id: <B3415038-3593-4C0F-9096-BB83213DBB47@umd.edu>
To: "lisa.seeman" <lisa.seeman@zoho.com>
Alastair makes a good point


Unless there is an automated tool — (a web crawler that can detect all the navigation elements and test them) This would take forever.   but I think it’s doable if there’s some group that wants to put up the funds to make it happen.

If we do this, we will need to recognize that many sites will still have navigation with complex words. If the most common word is complex word,  it would still pass. But I think this is okay. That means that sites with unnecessarily complicated navigation words would use more common words. And sites that are talking about complex topics would still be able to use appropriate words. That is, a site selling laboratory equipment could use proper technical terms to describe the categories of equipment etc.

It would be a perfect fit to Albert Einstein’s advice

“ everything should be is made as simple as possible, and no simpler"




g 

Gregg C Vanderheiden
greggvan@umd.edu




> On May 22, 2017, at 9:06 AM, lisa.seeman <lisa.seeman@zoho.com> wrote:
> 
> Would we all be more comfortable if we just had 
> 
> "Provide words or phrases  or abbreviations that are the most-common form to refer to the concept "
> 
> 
> Use of word frequency lists and core vocabularies could then be techniques.
> 
> This is harder to test.  The manual way to test it might be to look at a thesaurus and see if any of the words that mean the same thing and  are more common.
> 
> MS and IBM have tools that can test for the most common word. MS review tools are available with a subscription to their cloud. (i am not sure if this is true in all languages) but I can reach out to them and ask if we like this direct.
> 
> 
> 
> All the best
> 
> Lisa Seeman
> 
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter <https://twitter.com/SeemanLisa>
> 
> 
> 
> 
> ---- On Wed, 17 May 2017 11:31:08 +0300 Alastair Campbell<acampbell@nomensa.com> wrote ---- 
> Jason wrote:
> 
> > As mentioned, I’m still thinking through the implications and the feasibility here, but we do need to look beyond conventional approaches to defining and evaluating content requirements if we are to take some issues (especially but not only cognitive ones) into account in an authentic and effective way.
> 
>  
> Indeed, I have long maintained [1] that where improving accessibility crosses over into usability, you need to apply a certain process rather than guidelines. Most of the work my company does is apply user-centred-design, i.e. UX services for clients.
> 
>  
> Taking an example relevant to plain language (i.e. using 1500 common words), if you want to ensure a usable navigation menu for a content-oriented website then I would want to follow a particular process such as:
> 
> -          Open card sorting to establish how your audience think about the groupings of content and what grouping terms they associate with the content [2].
> 
> -          Create a navigation that seems to work for that content & mental model based on the results.
> 
> -          Closed card sorting (often with larger numbers) to refine and prove it works [3]. You can put then percentages on how well each term & content grouping works, and refine until it is optimised enough.
> 
>  
> The two points I’d make are:
> 
> 1.       There is no guideline that can help you predict the outcome of what a ‘usable’ navigation will be, it is based on content, context and audience. Every time in the last 16 years we have run the above process we massively improve a navigation that was created without it. Provably.
> 
> 2.       Arbitrarily using words from a common list it likely to make it less usable for the majority of the audience and cost organisations money.
> 
>  
> Take the navigation of an ecommerce store for example: https://www.johnlewis.com/ <https://www.johnlewis.com/>  I think there are more than 1500 words in the navigation! Also, it has (I assume) been finely honed over the years to maximise the usability for their customers.
> 
>  
> There is no reasonable argument to say that restricting their navigation to an arbitrary 1500 words is going to improve the experience for anyone. You could argue the interface should be simplified (e.g. like the small screen version) so less is presented at once, but many of the terms are objects or categories of things you can buy with specific names you can’t change.
> 
>  
> If they were asking my advice, I could not in good conscience tell them to restrict their navigation terms to the top 1500 words, it would cost them a lot of money for zero improvement for anyone.
> 
>  
> On the other hand, usability testing (with anyone but especially people with cognitive issues) or using the card-sorting process above would hugely improve most navigations for everyone, and with less political resistance (in an organisation) because they see the improvements first hand.
> 
>  
> For me this is something that needs to be dealt with in Silver, and a key part of Silver needs to be dealing with the *process* of making sites usable, as well as accessible. Ideally drawing on (or referring to) the ISO standards for user-centred-design and highlighting aspect particularly relevant for cognitive (and other) disabilities.
> 
>  
> In the meantime, can we move this one to the Cognitive TF note going out next to 2.1?
> 
>  
> Kind regards,
> 
>  
> -Alastair
> 
>  
> 1] https://lists.w3.org/Archives/Public/w3c-wai-gl/2015JulSep/0037.html <https://lists.w3.org/Archives/Public/w3c-wai-gl/2015JulSep/0037.html>
> 2] https://www.usability.gov/how-to-and-tools/methods/card-sorting.html <https://www.usability.gov/how-to-and-tools/methods/card-sorting.html>
> 3] https://www.optimalworkshop.com/treejack <https://www.optimalworkshop.com/treejack>
>  
> 
> 
Received on Monday, 22 May 2017 13:38:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 May 2017 13:38:15 UTC