Re: personalization as a technique - was Re: New Wiki page with SC text proposals to combine issues 79, 78, and 74

Hi Lisa,

Oh, I seem to be missing your original email, I can only see Laura's, sorry if I have missed something.

It would be great to incorporate some attributes for low vision.

I would just clarify that the SCs in the subject line we are trying to combine should apply without the need for personalisation.

For those to go further than the levels specified would require personalisation, so Laura's set is good.

I'll check out the links, I would be in a good position (apart from having time) to co-ordinate, but it would help for someone else to volunteer as well so we have a back-up / tag-team.

Cheers,

Alastair


Sent from my phone, apologies for typos.

_____________________________



Hi Lisa,

Interesting. Are you thinking of adding attributes for low vision that
would address 79, 78, and 74 such as:

lowvision-fontfamily
lowvision-foreground
lowvision-background
lowvision-lineheight
lowvision-letterspacing
lowvision-wordspacing

Thank you!

Kindest regards,
Laura

On 1/30/17, lisa.seeman <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>> wrote:
> Hi Alistair and Low Vision task force
>
> We are working on a full personalization architecture and will have a free
> browser extension
>
> We will have a specification for both the semantics and the personalization
> settings https://w3c.github.io/personalization-semantics/ it is under the
> aria working group.
> A first open implementation is at
> https://github.com/ayelet-seeman/coga.personalisation and there is a demo at
> http://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html
> IBM and Pearson are saying they intend also to implement it (although
> clearly I can not commit for either of them by CR it should have at least 2
> implementations )
>
> Should someone from the low vision task force coordinate with me to ensure
> LV personalization settings are fully addressed?
>
> Also than you can add personalization as a technique. This makes it much
> easier to make it widely applicable.
>
> We are addressing the testing burden by having a maximum of 5 recommended
> settings per user setting. So developers can test all recomended settings by
> testing against 5 templates.
>
> All the best
>
> Lisa Seeman
>
> LinkedIn, Twitter
>
>
>
>
>
> ---- On Wed, 25 Jan 2017 01:16:54 +0200 Alastair
> Campbell&lt;acampbell@nomensa.com<mailto:acampbell@nomensa.com>&gt; wrote ----
>
> Hi everyone,
>
> Thinking about the(se) adaptation Success Criteria, I really think the
> process is more important than the SC text at this stage.
>
> As I outlined before:
> https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/0418.html
>
> I think we need an *open* process to test the limits of what a user-side
> script or extension can do, to find out what authors can reasonably do.
>
> These things are not new, the Opera browser used to have user-stylesheets
> that adjusted colours, layouts etc. There are extensions now that pull out
> content and re-format it. But there is no standard, no one has tried to
> define it in an open way.
>
> We need to have a preliminary requirement (SC text), then test, write and
> test again.
>
> If we don't have an initial stake in the ground (of the SC text) then there
> is no point putting the effort into testing and writing techniques, but if
> we do, we have a plan and the SC text can be modified later based on the
> results.
>
> Cheers,
>
> -Alastair
>
>
>
>
>
>
>
>
>


--
Laura L. Carlson