RE: Whta COGA is doing with personlization - was Extension conflict/compatibility requirement

It is so good we are discussing all this for individuals with cognitive, learning and communication difficulties.

As Lisa says the main problem with regards to supporting symbol users online is the lack of standardisation of symbol sets and the individual way they are used.  I know Sign language users have their own gesture contractions for spoken speech and this can be the case for symbol users but with less standardisation when compared to signers.

Personalisation is key for those with communication difficulties and Lisa is right, it is hard to map symbols from one symbol set to another without the right ontology or linked data but I am a bit concerned about saying “That means end-users can only use one device, and cannot use apps or AT from a different company.”

Most devices and apps can import other symbols or personal pictures.  Most software allows for any individual symbol with its unique ID to be added to the device’s database as long as it is in a similar format.   However, as Lisa mentioned users may need to buy a licence to use the commercial symbols sets and schools, organisations and even device companies tend to choose just one symbol set that suits their needs.   So with no interoperability via a common vocabulary developers cannot ever hope to offer a ‘Google type’ symbol translation system.

Many thanks Lisa for taking this on and I do hope that helps as I know this is a complex subject and I am putting on my Speech and Language Therapist hat.

Best wishes
E.A.

Mrs E.A. Draffan
WAIS, ECS , University of Southampton
Mobile +44 (0)7976 289103
http://access.ecs.soton.ac.uk<http://access.ecs.soton.ac.uk/>
UK AAATE rep http://www.aaate.net/

http://www.emptech.info<http://www.emptech.info/>

From: lisa.seeman [mailto:lisa.seeman@zoho.com]
Sent: 19 October 2015 19:08
To: Gregg Vanderheiden <gregg@raisingthefloor.org>
Cc: Mike Pluke <Mike.Pluke@castle-consult.com>; Jonathan Avila <jon.avila@ssbbartgroup.com>; Allen Hoffman <allen.hoffman@hq.dhs.gov>; Laura Carlson <laura.lee.carlson@gmail.com>; Joshue O Connor <josh@interaccess.ie>; GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Subject: Whta COGA is doing with personlization - was Extension conflict/compatibility requirement

Hi Folks
As I understand it what we are doing is / will be compatible with GPII but are different pieces

Here is the summary...


We need personalization because:

  1.   Learning new design patterns (and widgets) can be confusing - we want to allow users to stick with what works for them  and not what works for others
  2.  Extra support can be annoying to people who do not need it
  3.  Making content predictable is necessary for accessibility but can often be considered boring design by some...
  4.  Ability to change levels of complexity (increase or decrease) - As people skills improve or decrease over time or context.
  5.  Enable us to really meet the user needs

Some users need extra support. This can include: Symbols and graphics that they are familiar with, Tool tips, Language they understand, Less features, Separating advertisements, so they do not confuse them with native content, Keyboard short cuts

We need standardized terms and supportive syntax that can be linked to associated symbols, terms, translations and explanations for the individual use via an aria attribute and personal preferences.



It is made of 4 parts:

  1.  Json files for user setting: https://github.com/ayelet-seeman/coga.personalisation/tree/JSON-Script

  2.  Aria proposal for new syntax: See https://rawgit.com/w3c/coga/master/issue-papers/links-buttons.html for latest draft
  3.  HTML pages that uses some of the new aria syntax - there is an example at: https://github.com/ayelet-seeman/coga.personalisation/tree/ExampleWebPage/

  4.  Scripts that a web author can use or include that read the user settings in the JSON files and adapt the page for the user needs. Again we have an example: https://github.com/ayelet-seeman/coga.personalisation/tree/Script-Options . What scripts or code or mechanism is used to apply the personlization is up to the author.

This is only one example way to use the semantics. Others may follow. It is also worth noting that the GPII project is working on making user preferences portable which would also enhance this work.

For example, assume an author can make it programanticaly known that a button is used to send an email. At at the user end, the button could be renderer with a symbol, term, and/or tooltips that is understandable for this particular user. It could automatically imply F1 help that explains the send function in simple terms. It could be identified with a keyboard short cut that will always be used for send. In addition it could be identified as important and always rendered, or rendered as a large button.

Working examples of how this could be used in practice with user preferences are available at https://github.com/ayelet-seeman/coga.personalisation. This is a project to help personalization for any use - including people with learning and memory issues. It is described more at: https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Easy_Personalization.




In another use-case we would like to see interoperable symbol set codes for non-verbal people. Products for people who are non vocal often use symbols to help users communicate. These symbols are in fact peoples language. Unfortunately many of these symbols are both subject to copy write and are not interoperable. That means end-users can only use one device, and can not use apps or AT from a different company. An open set of references for symbol codes for these symbol sets however, could be interoperable. That means the end use could use an open source symbol set or buy the symbols and use them across different devices or applications. Symbols could still be proprietary but they would also be interoperable.

Hope it makes sense

All the best

Lisa Seeman

Athena ICT Accessibility Projects <http://accessibility.athena-ict.com>
LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>



---- On Mon, 19 Oct 2015 20:50:45 +0300 Gregg Vanderheiden<gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>> wrote ----
yes

in Cloud4all/GPII we define 5 layers of personalization


  1.  features/options built into platform (e.g. access features in OS)
  2.  installed features/options  (e.g. Assistive technologies installed on a computer)
  3.  user-agent features/options  (e.g. access features in browsers)
  4.  cloud based features/options  (e.g. cloud based AT)
  5.  website based features/options  (e.g. features of the actual site)

We are working in Cloud4all/GPII to create  "auto-personalization from preferences” (APfP) capability that can span all 5 layers - coordinating among them and allowing the user to determine which features at which levels work best in which situations.



gregg

----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>



On Oct 19, 2015, at 10:57 AM, Michael Pluke <Mike.Pluke@castle-consult.com<mailto:Mike.Pluke@castle-consult.com>> wrote:

Yes, “user agent settings, assistive technologies, or through site controls/GPII preferences” was exactly the range of personalization options I had in mind. People may not immediately think of all of these options when considering personalization, but they are all valid if they deliver the desired effect.

I think that the rest of your message gives some very valuable warnings that we cannot rely on personalization always being available and that its existence is not an excuse for failing to deliver default solutions that meet as many non-conflicting accessibility requirements as possible.

Best regards

Mike

From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
Sent: 19 October 2015 16:50
To: Michael Pluke <Mike.Pluke@castle-consult.com<mailto:Mike.Pluke@castle-consult.com>>; lisa.seeman <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>>; Hoffman <allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>>
Cc: Laura Carlson <laura.lee.carlson@gmail.com<mailto:laura.lee.carlson@gmail.com>>; Joshue O Connor <josh@interaccess.ie<mailto:josh@interaccess.ie>>; WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>; Gregg Vanderheiden <gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>>
Subject: RE: Extension conflict/compatibility requirement

> How that personalization is delivered is not such an easy question to answer. In practice it is likely that there will never be just one way in which it can be achieved.

Yes, and this is the challenge as we have to find a common middle ground that is required but then also allow for adaptation in either direction.   The method of the adaption may be through user agent settings, assistive technologies, or through site controls/GPII preferences.

For example, under SC 1.4.8 there needs to be a mechanism to allow for line spacing to be set to 1.5 times.  This could be achieved by setting all content to line spacing of 1.5 the default size.  But this might be problematic for some users.  The user might be able to apply a custom style sheet to change this – but applying a custom style sheet might be difficult or impossible for some.  So site controls or user preferences (automated or not) are the best options.   However, do the challenges with user preferences and limitations such as mobile user agents authors may choose to adopt a one size fits all approach simply to meet the standards.

In regards to contrast – while contrast can be set via style sheets I’d continue to affirm that we need default contrast minimums because correctly setting sufficient foreground and background colors in stylesheets without blowing away visual affordances is very difficult or impossible IMO.  That is – I don’t want to be forced into losing the colors of a page just to get sufficient contrast – sites should continue to support minimum contrast while at the same time allowing for users to customize as needed.

Jonathan

--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
Phone 703.637.8957
Follow us: http://www.facebook.com/#!/ssbbartgroup" target='_blank'>Facebook | http://twitter.com/#!/SSBBARTGroup" target='_blank'>Twitter | http://www.linkedin.com/company/355266?trk=tyah" target='_blank'>LinkedIn | http://www.ssbbartgroup.com/blog" target='_blank'>Blog | http://eepurl.com/O5DP" target='_blank'>Newsletter

From: Michael Pluke [mailto:Mike.Pluke@castle-consult.com]
Sent: Monday, October 19, 2015 11:29 AM
To: lisa.seeman; Hoffman
Cc: Laura Carlson; Joshue O Connor; WCAG; Gregg Vanderheiden
Subject: RE: Extension conflict/compatibility requirement

Hi All

I full agree with Lisa – personalization is the only way to resolve these conflicts.

How that personalization is delivered is not such an easy question to answer. In practice it is likely that there will never be just one way in which it can be achieved. Those working on GPII are doing great work to identify one, hopefully widely supported and available way to provide personalization. Other, narrower, ways of providing personalization already exist within various websites and services.

The main thing we can do at this stage is to identify where conflicts can exist and ensure that methods for delivering alternative solutions are defined. When and where personalization methods exist, these can then deliver the right solution to the right individual based on their needs and preferences.

Best regards

Mike

From: lisa.seeman [mailto:lisa.seeman@zoho.com]
Sent: 19 October 2015 15:55
To: Hoffman <allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>>
Cc: Laura Carlson <laura.lee.carlson@gmail.com<mailto:laura.lee.carlson@gmail.com>>; Joshue O Connor <josh@interaccess.ie<mailto:josh@interaccess.ie>>; WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>; Gregg Vanderheiden <gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>>
Subject: RE: Extension conflict/compatibility requirement

Hi All
Without personlisation or allowing for alternative renderings for accessibility for cognitive will always be half baked and we will be  sacrificing the less vocal, but not less in need, groups  for the sake of the groups that have better representation.


I think any SC should be reachable via personlisation so long as the group in question has easy usable access to the personlization process.
All the best
Lisa Seeman

Athena ICT Accessibility Projects <http://accessibility.athena-ict.com/> LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>





---- On Mon, 19 Oct 2015 17:08:56 +0300 Hoffman<allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>> wrote ----

See the raising the floor global initiative.
Personalization with optional features is certainly no problem, but should not be promoted as the standard baseline solution. For example, one solution I know of offers ability to show graphs and tablular data that graphs are generated from, however, keyboard access and use of color are not addressed. Options for use of shading/patterns in graphs and more conforming tables are there, but should not be used as extensions, but should be there in baseline with optional extensions to add even more functionality.


Allen Hoffman
Deputy Executive Director
The Office of Accessible Systems & Technology
Department of Homeland Security
202-447-0503 (voice)
allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>

DHS Accessibility Helpdesk
202-447-0440 (voice)
202-447-0582 (fax)
202-447-5857 (TTY)
accessibility@dhs.gov<mailto:accessibility@dhs.gov>

This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain sensitive and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited.  If you have received this message in error, please reply immediately to the sender and delete this message.  Thank you.


-----Original Message-----
From: Laura Carlson [mailto:laura.lee.carlson@gmail.com]
Sent: Monday, October 19, 2015 8:13 AM
To: Joshue O Connor
Cc: WCAG; Gregg Vanderheiden; Lisa Seeman
Subject: Re: Extension conflict/compatibility requirement

Hi Josh and all,

Kathy astutely pointed out in last week’s teleconference [1] that people with disabilities may have opposing needs. For example, high contrast isn't good for certain people with cognitive or learning disabilities. David perceptively talked about how developers will just throw up their hands if extensions conflict with each other. It was suggested that conforming alternatives could address most of the conflicts but James wisely said testing would be a nightmare.

I agree with all of these observations.

One size doesn't always fit all. However, to get extension acceptance and uptake from the individuals and organizations that implement and/or use WCAG such as Web designers and developers, policy makers, purchasing agents, teachers, and students, extension conflicts should not be allowed. Moreover, if conflicts are allowed between extensions, I suspect it will lead to turmoil in the accessibility community between the very user groups that the extensions are trying to help.

So what can we do? Accessibility is essentially dealing with diversity.

Josh, I wonder, what ways exist for technology to provide personalization and customization of content to deal with diversity of users needs while at the same time eliminating extension conflicts in order to get extension buy-in from the individuals and organizations that use WCAG? What schemes exist or can exist for technology to afford users a method to receive information in accordance to their needs and capabilities?

GPII [2] is pioneering interoperable personalization schemes. Lisa and the Cognitive Task Force have been working on a proposal for an extension, where personalization is key. Could something such as these schemes help us avoid and eliminate conflicts? Is possible, say for in Kathy’s example, for users to receive whatever contrast they need via customization? Or is that wishful thinking? Perhaps Gregg V and Lisa could talk about feasibility.

Kindest Regards,
Laura

[1] http://www.w3.org/2015/10/13-wai-wcag- minutes.html [2] http://gpii.net/



On 10/16/15, Joshue O Connor <josh@interaccess.ie<mailto:josh@interaccess.ie>> wrote:
> Hi all,
>
> On the working group call this week there were a couple of interesting
> points raised regarding extensions that require further discussion. We
> also wish to engage other people on the list who were not on the call,
> and make sure that they are aware of some of the finer points and able
> to express an opinion here on the list.
>
> To sum up, two main 'themes' in our extension framework are extension
> compatibility, and the need to reduce, minimise or indeed remove any
> conflict between extensions.
>
> NOTE: As a thought experiment, one possible way to do that would be to
> have a 'MonoSpec' extension which combined the output from all TFs
> (Mobile/Cognitive/Low Vision) in a single spec. Potentially where care
> is taken to ensure that these extension SCs are fully compatible with
> each other there may be less 'conflict'.
>
> The 'PolySpec' extension approach would involve taking the SCs from
> each group and placing them in separate docs that conformance claims
> would be written against individually.
>
> While in principle, the contents of these docs would be more or less
> the same, the potential for conflict if there is only a 'MonoSpec' may
> be reduced. If only because a valid conformance claim would need to be
> written against it in toto. Also this approach would mean that devs
> would have to satisfy the success criteria in the MonoSpec fully, even
> if some are outside of the developers immediate area of interest. So
> in short could be a good way of conditioning developers to consider
> other user needs - rather than thinking "I need to make my content
> conform to just mobile, or low vision success criteria etc".
>
> Regarding extension conflict, in our current draft 'WCAG Extensions
> Framework' document it states: [2]
>
> "Ensure that all WCAG extensions are compatible with each other
> Extensions must not conflict with each other. This is important for
> the purpose of enabling content providers to implement support for
> more than one extension. For this reason will be critically important
> for group members working on different extensions to maintain good
> communication about extension work in progress."
>
> There are a couple of questions/points that arise:
>
> 1) Should we explicitly call out the need within the framework that
> there must NOT be conflict between extensions? It has been pointed out
> (rather practically) that it just may not be possible to avoid
> conflict with our extensions.
>
> 2) If we do explicitly call out this issue in our framework, it may
> help focus working group attention on carefully finding where there
> are conflicts in extensions (between there own group and others).
>
> 3) On a more granular level how do you think the framework should even
> define conflict?
>
> 4) Obviously while spec fragmentation is a concern inherent in the
> extensions discussion a final thought is the basic question; Is
> conflict always inherently bad? Can positive conflict or friction
> between various user requirements result in the end in better content,
> better user experience etc?
>
> What do you think?
>
> [1] http://www.w3.org/2015/10/13-wai-wcag-minutes.html

> [2] https://www.w3.org/WAI/GL/wiki/WCAG_Extensions_Framework


--
Laura L. Carlson

Received on Monday, 19 October 2015 21:32:14 UTC