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

+1

​​​​​* katie *
 
Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)
 
Cell: 703-371-5545 | ryladog@gmail.com | Oakton, VA | LinkedIn Profile | Office: 703-371-5545 | @ryladog

NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.


-----Original Message-----
From: Alastair Campbell [mailto:acampbell@nomensa.com] 
Sent: Thursday, February 16, 2017 5:06 PM
To: W3c-Wai-Gl-Request@W3. Org <w3c-wai-gl@w3.org>
Subject: Re: UA tools & adaptation, was: "we should not allow user testing in exceptions"

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

Received on Friday, 17 February 2017 15:18:40 UTC