Re: Personalisation: meta-data vs button(s) on page

+1 in general Alastair

I'd add that, acceptance would be contingent upon the coga attributes spec
being an accepted recommendation by the W3C and stable before the WCAG 2.1
standard is released. and also that there is a reasonable expectation that
there will be AT or browser capability to do something with it.

Otherwise, I think it's like a introducing wai-aria requirements before the
existence of screen readers.

On Friday, June 30, 2017, Alastair Campbell <acampbell@nomensa.com> wrote:

> Hi everyone,
>
>
>
> Starting a new thread for this aspect of personalisation, about how the
> fall-back mechanism works in the SC text.
>
>
>
> I understand from Lisa that providing the meta-data is the preferred
> method (the second bullet), but due to overhead there was a wish that an
> on-page version could conform. The recent SC text starts:
>
>
>
> “For pages that contains interactive controls or with more then one
> regions, one of the following is true:
>
>
>
>    - a mechanism is available for personalization of content that enables
>    the user to add symbols to interactive controls OR…”
>
>
>
> *I am not convinced this is any less work than the second bullet, so I am
> confused about what benefit it adds?*
>
>
>
> Assuming people don’t just do an absolute minimum, the process for both
> would be:
>
>
>
>    1. Assess your page templates against the coga-personalisation spec
>    and work out what meta-data is suitable.
>
>    2. For static elements things like header/main/footer they can be
>    added to the templates.
>
>    3. For dynamic elements like a CMS-driven menu this will involve a
>    fair bit of programming. Also, if CMS users can add things to the menu it
>    will cause a huge overhead of adding meta-data fields to menu items, AND
>    training users to know what to do with them. (E.g. how does a press officer
>    adding a sub-section to their news page know what to do with coga-context?
>    Even if the answer is nothing, it is still a question that they will ask
>    and need answered.)
>
>    4. Testing that if someone applies customisations the whole site
>    doesn’t fall apart in a big mess.
>
>    5. Update the layout and possibly the design in order to allow for
>    icons to be added, text to change size, backgrounds to change.
>
>
>
> I’ve gotten to know the coga-personalisation spec and can see how *some*
> of them can be applied. I haven’t worked out the testing aspect yet and
> this is probably the biggest overhead.
>
>
>
> There are too many connotations for the author side to be responsible for.
> Teams already spend a huge proportion of time browser-testing, (small)
> device testing, hopefully AT testing. This is adding another layer to the
> matrix, so for every connotation (icons, text size, colour scheme, hidden
> elements) people would have to test everything again, it is a multiplier
> effect where it multiplies the QA testing time needed.
>
>
>
> It isn’t just a little bit extra, and it doesn’t matter if it is an
> on-page control or a user-side script, the testing should be the same in
> either case.
>
>
>
> I think there are a couple of options to get around it:
>
>
>    - Have *one* set of criteria for people to test with (like the LVTF
>    have been trying to do with text-adaptation). E.g. max-out the icons,
>    text-size and show all options as the test case.
>    That would need to be defined now and be part of the SC text otherwise
>    the SC is not testable.
>
>    - Drop the first bullet, focus the SC on applying meta-data, and don’t
>    make it an author responsibility to test the effects of using the
>    meta-data.
>
>
>
> I’d opt for the second, that is the ‘something’ to get in now, and can be
> built on.
>
>
>
> Cheers,
>
>
>
> -Alastair
>


-- 
Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Mobile:  613.806.9005

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>