Re: UA tools & adaptation, was: "we should not allow user testing in exceptions"

I support trying something that is at risk if we have reasonable
expectation of it being solved or if individuals from the group are doing
development that is promising. We did that with the colour contrast
analyser.

We can leave SCs off or adapt SCs for the Final draft where expected
solutions haven't materialized.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Thu, Feb 16, 2017 at 5:05 PM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> I'd like to clarify something from David's point here:
>
> > The fact that we are trying to create a plugin that linearizes content,
> to show that it can be done, and are encountering many problems in the
> process, shows that there are currently no existing tools doing this.
>
> Firstly, I'd like to draw a distinction between SCs that require a UX
> process or usability testing (where this thread started), and SCs which are
> pushing up the adaptation/personalisation levels (e.g. linearisation).
>
> There *are* tools that do linearisation now, for example: Safari's reader
> mode, the "Just Read" plugin, Instapaper, and the Web developer toolbar's
> "Linearise page" feature. But they don't meet the LV needs, partly because
> the weren't designed to, and partly because there isn't a standardised
> method for linearising a page.
>
> I have heard from people on the list that two other UA tools in this area
> are in active development.
>
> As David then said:
> > There has been almost no progress on these tools since WCAG 2.
>
> We need to break the chicken & egg situation: Authors have no reason to
> think about linearisation (beyond responsive design) because there are no
> recognised tools for users (or an SC), and tools won't be created because
> it is too hard to linearise the infinite variety of web pages with not
> standard way.
>
> The tools are currently flaky, but no-one has established if that's
> because they are just flaky, or because authors need to do certain things
> to enable them, or simply not disrupt them.
>
> We proposed a method (for linearisation and text-adaptation) to try and
> break that cycle, within the WCAG 2.x framework:
> - Get an initial SC into the FPWD.
> - Setup a test repository of user-agent-side scripts [1], open to all.
> - Test those scripts against lots of real-world websites (spreadsheet
> city).
> - Iterate the scripts, make sure that where there are problems, they are
> things the website is doing that cannot be overcome on the user-agent side.
> - Use github to track issues, get contributions.
> - Generate techniques and failures for the things that websites have to do.
> - If that task is impossible, or the group doesn't feel there are
> sufficient techniques, we'll have to drop or defer the SC.
>
> There is more discussion of an objection-response nature [2], but that's
> the summary of the approach.
>
> It's a lot of work, it's risky (in that it might not get into WCAG 2.1),
> but I think it is worth trying because even if it doesn't get in, we'll
> have a body of evidence on the issues, and hopefully code techniques (under
> an open source license) that can be picked up by any future work.
>
> Cheers,
>
> -Alastair
>
> 1] https://github.com/alastc/adaptation-scripts
> 2] https://github.com/w3c/wcag21/pull/89#issuecomment-278289086
>
>