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

+1 to Laura's list of LVTF personalization attributes.  I would also
suggest adding:

lowvision-inactivecontrol (related to LVTF Issue #9
https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Contrast_(Minimum))
 Sometimes in discussion we referred to this as a "disabled" control, but I
think it would be best moving forward to change this to "inactive".

Specifically - The color contrast needs for inactive form controls has
conflicting solutions for some low vision users and some users with
cognitive issues. Therefore, the color contrast needs for inactive (or
disabled) elements needs a preference control and it will be well suited
for Silver.

Additional thoughts from LVTF wiki:

Recommended for Silver

Due to the different needs and preferences of low vision users, the
contrast requirements for inactive user interface components (also known as
disabled interactive elements) is recommended for inclusion in Silver.
RECOMMEND adding an ARIA-status of "inactive" so automated testing tools
can ignore. A solution to consider for Silver is to make it a preference to
"enhance color contrast for Low Vision AND/OR add a symbol for "inactive
user interface components".'
inactive user interface component
a user interface component that is visible but not currently usable.
Example: A submit button at the bottom of a form that is visible but cannot
be activated until all the required fields in the form are completed.
Inactive Submit Button Example for Silver


   - An inactive submit button that has an "X" on it indicating that this
      button is not active yet.


Let me know if y'all have questions.

G

glenda sims    |   team a11y lead   |    deque.com    |    512.963.3773


*web for everyone. web on everything.* -  w3 goals

On Mon, Jan 30, 2017 at 10:51 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> 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> 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&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
>
>
>