search

w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
140 stars 55 forks source link

Support Personalization #6

Closed lseeman closed 7 years ago

lseeman commented 8 years ago

Current versions of SC and Definitions

SC Shortname

Support Personalization (minimum)

SC Text

A version of the content is available such that one of the following is true:

Suggestion for Priority Level

(A)

Related Glossary additions or changes

Contextual information
semantics and tags that give meaning to the content such as context of elements; concept and role; relevance and information for simplification; position in a process
Personalization
user interface that is driven by the individual user's preferences
Author settable properties
type of distraction, type of help, type of transaction and type of reminder, instructions and status of an element
critical features
features that are required to complete the main role or tasks of the user interface
important information
information the user may need to complete any action or task including an offline task, or related to safety, risks, privacy, health or opportunities
standardized technique
part of a W3C standard, the standard of the native platform, or a WCAG technique (please note: other success criterion have better definitions for this term)

What Principle and Guideline the SC falls within.

This could fall under:

WCAG 1 Perceivable - Guidline 1.3 Create content that can be presented in different ways (for example simpler layout) without losing information or structure

Description

The intent of this success cryteria is to support user preferences or needs of the user. For example, having familiar terms and symbols is key to being able to use the web. However what is familiar for one user may be new for another requiring them to learn new symbols. Personalization could include loading a set of symbols that is appropriate for the specific user, ensuring that all users find the icons simple and familiar.
Technology holds the promise of being extremely flexible and the design of many systems includes the expectation that users will be able to optimise their interaction experience according to their personal preferences or accessibility requirements (needs).

Benefits

This Success Criterion helps users who need extra support or a familure interface. This can include:

We need personalization because:

This helps people with many diffrent cognitive disabilities including people with:

Togther this can effect 11% of school age people and over half of people over 60 years old - including mild cognative imparment an Age-Associate Memory Impairment (AAMI).

Research on these benefits can be found at [cudd-1] and the task forces issue-papers on personalization and preferences. Also see the example of an adaptive page.

An example is a user can be a person growing older whose ability to learn new things has slowed down. This includes learning new interfaces, symbols and designs. They also rely on tool tips. So long as the design is on they know they can use the application and stay in the work force. When the interfaces change, they tryand learn the new interface, but the cognitive load becomes to great and they need to retire. Another example:

"Research has shown that dementia changes a person's perception of distances, objects, and colours. Dementia can reduce or remove the ability to see colours from the blue to purple end of the spectrum. Decorative patterns can 'strobe' and possibly confuse or unsettle people. Even something as simple as a silver strip between different floor coverings in a doorway can appear to a person with dementia like something threatening, such as a step or a hole."

Taken from https://www.alzheimers.org.uk/site/scripts/documents_info.php?documentID=2591

Related Resources

Resources are for information purposes only, no endorsement implied.

Testability

General test

For HTML and Web Content

  1. Identify the role of elements
  2. Identify the context of regions and controls
  3. Check that the context and role is clear from the markup - if not add the role and context from native HTML, ARIA and COGA (where it is supported)
  4. Ensure content conforms to those standards where they can be used for personlisation or additional support.and set the applicable auther settable properties

Techniques

Techniques include:

The following are common mistakes that are considered failures of Success Criterion 3.1.1 by the WCAG Working Group.

  1. standardized semantics for personalization were appropriate and not used.
  2. standardized platform technique for personalization were appropriate and not used.
joshueoconnor commented 7 years ago

Assigned to Jan McSorley - https://www.w3.org/WAI/GL/wiki/SC_Managers_Phase1

mbgower commented 7 years ago

As a goal, I am all for supporting personalization. As noted here,

Technology holds the promise of being extremely flexible

But my concerns are also tied up in that same statement; "holding promise" is a difficult future vision to build a current SC upon. My perception is that authors have no existing standardized semantics to cover this that aren't already requirements for other SC. Until such semantics are developed and adopted, it's pretty tough to implement this, especially as a level A requirement.

My gut feeling on this is that in the near term personalization could comprise a series of techniques or methods that can be used to meet more targeted success criteria. That could mean working to create new Personalization scenarios under the Sufficient Techniques section of existing SC. For example, Timing Adjustable could have a new scenario "Where personalization is supported" that outlines what techniques can be used to support adjusting timing on a user preference basis.

Once the ecosystem better supports it (specification in place, adoption of personalization techniques by WCAG and UAAG) then I think we may approach a time when there could be value in a generic Support Personalization SC to catch failures. But we also might find that this need will be best expressed as one or more failure techniques which can be applied to any of those situations where personalization can be used to satisfy other SCs.

lseeman commented 7 years ago

Mike we have semantics that are freely available at https://github.com/w3c/personalization-semantics/ we have an open implementation at https://github.com/ayelet-seeman/coga.personalisation Both Pearson and IBM are saying they will be implementing it once it is in a working draft so by the time we get to CR we should have everything

lseeman commented 7 years ago

https://w3c.github.io/personalization-semantics/

jmcsorle commented 7 years ago

Hi Mike,

Thank you for your comment. This SC has been assigned to me to manage. It would be very helpful to learn from you what you think this still needs in order to be moved on to CR. Specifically, I was hoping that you could provide some additional details about the following statement you made: "My gut feeling on this is that in the near term personalization could comprise a series of techniques or methods that can be used to meet more targeted success criteria."

In the education industry and in assessment, personalization is becoming increasingly important and there is a need for the W3C to bring clarity and stability to how to implement this. As more and more instructional and assessment resources are moving to digital and online formats, there are design principles moving through schools and education publishing companies, such as Universal Design for Learning, that are falling short of the kinds of detail needed to truly provide for the personalization needs of students with disabilities. I believe we need to seriously consider how to effectively address the issue of personalization in the next working draft, so I would like to have more dialog about why you and others may think this SC could compromise techniques or methods of other SCs. Could you please provide an example so that I can better understand your concerns? Thanks again for your help!

Thanks!

lseeman commented 7 years ago

Hi Mike I think we need a clear definition of what we need in place by CR beyond a working draft of semantics, freely available download for users agents (AT) and two implementations which we look like we will have

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Tue, 24 Jan 2017 06:34:39 +0200 jmcsorle<notifications@github.com> wrote ----

Hi Mike, Thank you for your comment. This SC has been assigned to me to manage. It would be very helpful to learn from you what you think this still needs in order to be moved on to CR. Specifically, I was hoping that you could provide some additional details about the following statement you made: "My gut feeling on this is that in the near term personalization could comprise a series of techniques or methods that can be used to meet more targeted success criteria." In the education industry and in assessment, personalization is becoming increasingly important and there is a need for the W3C to bring clarity and stability to how to implement this. As more and more instructional and assessment resources are moving to digital and online formats, there are design principles moving through schools and education publishing companies, such as Universal Design for Learning, that are falling short of the kinds of detail needed to truly provide for the personalization needs of students with disabilities. I believe we need to seriously consider how to effectively address the issue of personalization in the next working draft, so I would like to have more dialog about why you and others may think this SC could compromise techniques or methods of other SCs. Could you please provide an example so that I can better understand your concerns? Thanks again for your help! Thanks! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

mbgower commented 7 years ago

I would like to have more dialog about why you and others may think this SC could compromise techniques or methods of other SCs. Could you please provide an example so that I can better understand your concerns?

Adoption of WAI-ARIA would be an example of what I'm discussion. There was no "Support ARIA" SC introduced. Instead, 21 ARIA success techniques have been written and incorporated into existing SCs. They were added to:

That sounds like a good starting list for Personalization techniques in exisiting SCs. There are others, including some 2.1 candidates, which could take advantage of Personalization techniques.

WAI-ARIA 1.0 also serves as an example of adoption time lines. The first public draft came out in 2006. It went through two years of working drafts before a last call. Then another year of drafting before a second last call. I believe between these two last calls is when the first draft WCAG ARIA techniques and the first fledgling browser support appeared. It became a candidate recommendation in 2011, and a proposed recommendation three years after that. An eight year journey, with a progressive adoption of ARIA into browsers, techniques and ATs along the way.

I'd be curious why you don't feel such a model could be used for Personalization, which is likely facing a similar timeline.

lseeman commented 7 years ago

Success Criterion 4.1.2 (Name, Role, Value) is exactly the model we are using. It was added to support aria or any other mechanism that does the job in an interoperable way. We are following the same rout . Personalization will also be the easiest way to meet a whole bunch of other SC as well - just like with the aria roadmap (which I was heavily involved in writing)

In fact we were going to include a lot of the coga stuff in aria 1.0. we put it off so that the issue for dynamic pages with screen readers could be solved first.

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Tue, 24 Jan 2017 17:30:20 +0200 Mike Gower<notifications@github.com> wrote ----

I would like to have more dialog about why you and others may think this SC could compromise techniques or methods of other SCs. Could you please provide an example so that I can better understand your concerns? Adoption of WAI-ARIA would be an example of what I'm discussion. There was no "Support ARIA" SC introduced. Instead, 21 ARIA success techniques have been written and incorporated into existing SCs. They were added to: Success Criterion 1.3.1 (Info and Relationships) Success Criterion 3.3.2 (Labels or Instructions) Success Criterion 3.3.3 (Error Suggestion) Success Criterion 4.1.2 (Name, Role, Value) Success Criterion 1.1.1 (Non-text Content) Success Criterion 2.4.4 (Link Purpose (In Context)) Success Criterion 2.4.1 (Bypass Blocks) Success Criterion 3.3.1 (Error Identification) That sounds like a good starting list for Personalization techniques in exisiting SCs. There are others, including some 2.1 candidates, which could take advantage of Personalization techniques. WAI-ARIA 1.0 also serves as an example of adoption time lines. The first public draft came out in 2006. It went through two years of working drafts before a last call. Then another year of drafting before a second last call. I believe between these two last calls is when the first draft WCAG ARIA techniques and the first fledgling browser support appeared. It became a candidate recommendation in 2011, and a proposed recommendation three years after that. An eight year journey, with a progressive adoption of ARIA into browsers, techniques and ATs along the way. I'd be curious why you don't feel such a model could be used for Personalization, which is likely facing a similar timeline. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

mbgower commented 7 years ago

A big difference between Name, Role, Value and what you are proposing is in the note for 4.1.2:

Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

So Name, Role, Value is concerned with ensuring that authors who create custom widgets meet expected behaviour. If authors use HTML properly, there is no additional work.

As it reads now, Personalization would seem to require every author to use the author-settable properties and attributes in the draft COGA semanatics proposal or fail WCAG. That list at the moment includes about 2 dozen attributes, of which just a couple represent significant additional work. (Further, the list doesn't include Personalization outside the COGA realm that would support solutions for any number of other SCs, such as keyboard assignments, persistence/timing and location of tool tips and other non-persistent information, Audio Control, Pause-Stop-Hide, Abbreviations, etc.)

Focusing on techniques, which let authors choose to address various issues through a personalization solution, is a more easily adopted and incremental method. Contrast that with an implementation that seems to compel authors to begin adding Personalization to all pertinent content.

lseeman commented 7 years ago

Hi Mike

You would only add the ones that apply. Most have default values as well.

An example of a complaint site is http://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html (note some of the terms have changes) . As you cna see the semantics are not so much. When you add a type, you automatically add a lot of the other information. Also items like such as keyboard assignments can be the personalization settings (eg a user template of preferences) set by the user and not by the author

In addition IBM is coming out with an API's (based on watson) that can add the semantics automatically and the author will just confirm it. I am sure other companies will come out with similar tools if it makes it into WCAG. If it does not make it into WCAG then non of this happens and people will continue to be left out, as they are now.

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Tue, 24 Jan 2017 21:06:36 +0200 Mike Gower<notifications@github.com> wrote ----

A big difference between Name, Role, Value and what you are proposing is in the note for 4.1.2: Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification. So Name, Role, Value is concerned with ensuring that authors who create custom widgets meet expected behaviour. If authors use HTML properly, there is no additional work. As it reads now, Personalization would seem to require every author to use all the author-settable properties and attributes in the draft COGA semanatics proposal or fail WCAG. That list at the moment includes: coga-simplification coga-action coga-destination coga-field coga-context coga-concept coga-numberfree coga-literal coga-feedback coga-explain coga-moreinfo coga-extrahelp coga-helptype coga-hidden coga-alternative coga-easylang coga-messageimportance coga-messagefrom coga-messagecontext coga-messagetime coga-distraction coga-trigger Just a couple of these item represent significant additional work, and it doesn't even take into account Personalization outside the COGA realm that would support solutions for any number of other SCs, such as keyboard assignments, persistence/timing and location of tool tips and other non-persistent information, Audio Control, Pause-Stop-Hide, Abbreviations, etc. Focusing on techniques, which let authors choose to address various issues through a personalization solution, is a more easily adopted and incremental method. Contrast that with an implementation that compels all authors to begin adding all Personalization to all content. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

mbgower commented 7 years ago

You would only add the ones that apply. Most have default values as well.

Thanks for that clarification. Can I get more details on that, please? The draft doc mentions a few defaults, but it's not exhaustive. I edited out my initial list of your attributes, but if we're going to tackle this, I think we need them, especially considering your demo site uses different ones:

If we are going to assess the impact of this SC, I think there needs to be a lot more clarity on what attributes have defaults (and I'm assuming therefore no authoring requirement) and what require effort and how much.

If it does not make it into WCAG then non of this happens and people will continue to be left out, as they are now.

There are a number of existing and proposed SCs that either specifically mention personalization or could obviously be achieved with it. ARIA was incorporated into WCAG without a specific SC requiring its use; why can't personalization make it in without being an SC? I continue to have concerns about including an SC that at the moment is extremely hard to quantify for effort or scope -- even the demo site you point to uses completely different attributes. It makes for a shaky case for successful adoption, particularly for a level A.

lseeman commented 7 years ago

Hi MikeThadures is redoing the demo so the mappings should be clearer after the weekend.

Many of them are appropriate for specific types of content, for example coga-numberfree is on numeric information were a non numeric summary is available (see the spec fo the details) Clearly you would not put it on other content Log and related referrers to breadcrumb/history type elements coga-explain is on non standard controls Coga-literal is on non-literal language. etc

The thing to do will be to make sure the speck and the demo is clear (at least by the time it gets to CR) and not write the full speck over again in the this issue

If the speck is not clear it will not get to CR and will be mute

I would be happy to work with you on the speck

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Wed, 25 Jan 2017 20:43:11 +0200 Mike Gower<notifications@github.com> wrote ----

You would only add the ones that apply. Most have default values as well. Thanks for that clarification. Can I get more details on that, please? The draft doc mentions a few defaults, but it's not exhaustive. I edited out my initial list of your attributes, but if we're going to tackle this, I think we need them, especially considering your demo site uses different ones: coga-simplification coga-action coga-destination coga-field coga-context coga-concept coga-numberfree coga-literal coga-feedback coga-explain coga-moreinfo coga-extrahelp coga-helptype coga-hidden coga-alternative coga-easylang coga-messageimportance coga-messagefrom coga-messagecontext coga-messagetime coga-distraction coga-trigger On your demo page, I'm seeing endemic use of aria-importance (on pretty much all content) and common usage of aria-function. I'm not sure what aria-importance maps to on the above list. I'm assuming aria-function maps to coga-action? If we are going to assess the impact of this SC, I think there needs to be a lot more clarity on what attributes have defaults (and I'm assuming therefore no authoring requirement) and what require effort and how much. If it does not make it into WCAG then non of this happens and people will continue to be left out, as they are now. There are a number of existing and proposed SCs that either specifically mention personalization or could obviously be achieved with it. ARIA was incorporated into WCAG without a specific SC requiring its use; why can't personalization make it in without being an SC? I continue to have the concerns about including an SC that at the moment is extremely hard to quantify for effort or scope -- even the demo site you point to uses completely different attributes. It makes for a shaky case for successful adoption, particularly for a level A. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

jmcsorle commented 7 years ago

Mike, are you okay with this, or do you need Lisa to specify which attributes have defaults, including nonvalid, or are you comfortable taking her word that there will be sufficient defaults in the specification by the time it gets to working draft in a few months? If you want the defaults defined, we would prefer to make the edits in the specification. Please let me know if you have any additional thoughts or concerns related to this.

mbgower commented 7 years ago

@jmcsorle, yes, I agree the edits should be in the spec.

are you comfortable taking her word that there will be sufficient defaults in the specification by the time it gets to working draft in a few months?

If the spec working draft does not contain sufficient information by the time WCAG 2.1 goes to draft in a month, I think it's going to be tough to get support on this as it is. That's obviously just my opinion. It would be nice to get some others weighing in on this SC, which may prove \<span coga-literal="most people disagree with my opinion"> I'm out in left field! \</span>

I realize I am likely viewed as adversarial in this thread, but my approach to all the candidates has been to put on my critical hat and figure out what could keep the idea from being adopted. If there are scope problems, they need to be fixed; if there are language problems, they need to be rewritten; if it isn't really an author responsibility, it needs to be reconsidered, etc.

My concern with Support Personalization is that it seems both overly ambitious for the current circumstances (lack of user agent and AT support, and immaturity of supporting materials) and overly constrained (from the perspective that personalization could contain a great deal more than just cognitive, and be used to successfully address a number of other significant existing issues).

Ironically, I just got off a call where I was arguing on the other side of a similar discussion (this one around keyboard usage) about how authoring practices need to be in place to justify the need to get UAAG and AT buy-in. So why don't I leave this one alone for now and wait and see what someone else offers?

lseeman commented 7 years ago

maybe we should split this into two at level A have a limited scope of critical features and a have the orignal one as AA critical features and is already defined in # 39

the new sc would read: Support personalization: Contextual information and author settable properties of regions and critical features and important information are programatically determinable so that personalization is available.

Where the number of steps in a process can be reduced, the user can control the trade off between function and simplification.

Exception: Information does not need to be exposed when there is not a standardized way of exposing it in the technology or the platform.

Notes are the same as the original

joshueoconnor commented 7 years ago

@lseeman I don't see a GH username for Jan here. Is there a PR ready for this one or do you need more time?

lseeman commented 7 years ago

on the phone with mike G

mike and me discussed the following the new sc would read:

  1. Support personalization: Contextual information and author settable properties of regions, critical features and important information are programatically determinable so that personalization is available.

Exception: Information does not need to be exposed when there is not a standardized technique of exposing it in the technology or the platform.

note that critical features and important information and standardized technique are already defined terms at https://rawgit.com/w3c/coga/master/extension/index.html

we then have another sc (level A or AA)

Where the number of steps in a process can be reduced, and easily available mechanism exists to alow the user to control the trade off between function and simplification.

(techneques inlude marking things with aria-required, providing a less options button and using personlization etc)

at AAA we have Support personalization (all content): Contextual information and author settable properties of regions and elements are programatically determinable so that personalization is available.

jspellman commented 7 years ago

I see there are three separate success criteria here: Reduce the number of steps, provide contextual information, and provide customizable user preferences. This proposal is a little rough, but I would recommend:
1) Reduce Steps: Provide settings, shortcuts or other methods for return users so they can reduce the number of steps needed to perform a task. Example: A shopping cart that saves and pre-fills the address and credit card information.
2) Contextual Information: Provide explanatory text, simplified instructions, or descriptive images to improve clarity and provide multiple means of representation of a concept. Definition of Contextual Information is unclear whether it is needed or provided. Recommend: Contextual Information: Information necessary to the understanding of the text or term. (Beck, Isabel 2009 Robust Vocabulary Instruction) 3) Customizable User Preferences: Provide programmatically determinable semantics that allows the user (or their assistive technology) to make changes to their experience to meet their individual needs. This includes: number types (e.g. phone, dates, currency), interruptions (e.g. aria live regions), abbreviations, definitions or accordions with additional instructions or expanded information,

lseeman commented 7 years ago 
        I think each one of your suggested sc have a hugely increased scope to the one here. And I can not see a path off hand to making them clear and testable or widely applicable. It might be that you have identified three advantages to the sc, but Unless  we have a suggestion that is more likely to pass the bar we should probably stick with what we have. I think we need to define when steps can be reduced to avoid including the case you gave which would be a best practice.I think it can be defined as optional steps that are not required to complete the  task that the user has embarked on.Does that add clarity?All the bestLisa SeemanLinkedIn, Twitter---- On Thu, 09 Feb 2017 22:37:44 +0200  jspellman<notifications@github.com> wrote ----I see there are three separate success criteria here:  Reduce the number of steps, provide contextual information, and provide customizable user preferences.  This proposal is a little rough, but I would recommend:  Reduce Steps: Provide settings, shortcuts or other methods for return users so they can reduce the number of steps needed to perform a task.  Example: A shopping cart that saves and pre-fills the address and credit card information. Contextual Information: Provide explanatory text, simplified instructions, or descriptive images to improve clarity and provide multiple means of representation of a concept. Definition of Contextual Information is unclear whether it is needed or provided.  Recommend: Contextual Information: Information necessary to the understanding of the text or term. (Beck, Isabel 2009 Robust Vocabulary Instruction) Customizable User Preferences:  Provide programmatically determinable semantics that allows the user to make changes to their experience to meet their individual needs.  This includes: number types (e.g. phone, dates, currency), interruptions (e.g. aria live regions), abbreviations, definitions or accordions with additional instructions or expanded information,   —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.
lseeman commented 7 years ago 
        We could take out Where the number of steps in a process can be reduced, the user can control the trade off between function and simplification.And put that Into a separate scI suggest rewording it as follows:When a process contains optional steps that are not required to complete the primary task, the user can control the trade off between function and simplification.And define Primary task as: the core task the user has embarked on.I think splitting it further is getting a bit messy but I will sleep on itAll the bestLisa SeemanLinkedIn, Twitter---- On Fri, 10 Feb 2017 03:41:56 +0200  lisa.seeman<lisa.seeman@zoho.com> wrote ----I think each one of your suggested sc have a hugely increased scope to the one here. And I can not see a path off hand to making them clear and testable or widely applicable. It might be that you have identified three advantages to the sc, but Unless  we have a suggestion that is more likely to pass the bar we should probably stick with what we have. I think we need to define when steps can be reduced to avoid including the case you gave which would be a best practice.I think it can be defined as optional steps that are not required to complete the  task that the user has embarked on.Does that add clarity?All the bestLisa SeemanLinkedIn, Twitter---- On Thu, 09 Feb 2017 22:37:44 +0200  jspellman<notifications@github.com> wrote ----I see there are three separate success criteria here:  Reduce the number of steps, provide contextual information, and provide customizable user preferences.  This proposal is a little rough, but I would recommend:  Reduce Steps: Provide settings, shortcuts or other methods for return users so they can reduce the number of steps needed to perform a task.  Example: A shopping cart that saves and pre-fills the address and credit card information. Contextual Information: Provide explanatory text, simplified instructions, or descriptive images to improve clarity and provide multiple means of representation of a concept. Definition of Contextual Information is unclear whether it is needed or provided.  Recommend: Contextual Information: Information necessary to the understanding of the text or term. (Beck, Isabel 2009 Robust Vocabulary Instruction) Customizable User Preferences:  Provide programmatically determinable semantics that allows the user to make changes to their experience to meet their individual needs.  This includes: number types (e.g. phone, dates, currency), interruptions (e.g. aria live regions), abbreviations, definitions or accordions with additional instructions or expanded information,   —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.
lseeman commented 7 years ago 
        With regard to item two. Contextual information is a defined term.We could modify that definition as followsSemantics and tags that give meaning to the content such as context of elements; concept and role; relevance and information for simplification; position in a processThat should reduce the confusion between this sc and the one on help.Is it clearer now?All the bestLisa SeemanLinkedIn, Twitter---- On Fri, 10 Feb 2017 03:41:56 +0200  lisa.seeman<lisa.seeman@zoho.com> wrote ----I think each one of your suggested sc have a hugely increased scope to the one here. And I can not see a path off hand to making them clear and testable or widely applicable. It might be that you have identified three advantages to the sc, but Unless  we have a suggestion that is more likely to pass the bar we should probably stick with what we have. I think we need to define when steps can be reduced to avoid including the case you gave which would be a best practice.I think it can be defined as optional steps that are not required to complete the  task that the user has embarked on.Does that add clarity?All the bestLisa SeemanLinkedIn, Twitter---- On Thu, 09 Feb 2017 22:37:44 +0200  jspellman<notifications@github.com> wrote ----I see there are three separate success criteria here:  Reduce the number of steps, provide contextual information, and provide customizable user preferences.  This proposal is a little rough, but I would recommend:  Reduce Steps: Provide settings, shortcuts or other methods for return users so they can reduce the number of steps needed to perform a task.  Example: A shopping cart that saves and pre-fills the address and credit card information. Contextual Information: Provide explanatory text, simplified instructions, or descriptive images to improve clarity and provide multiple means of representation of a concept. Definition of Contextual Information is unclear whether it is needed or provided.  Recommend: Contextual Information: Information necessary to the understanding of the text or term. (Beck, Isabel 2009 Robust Vocabulary Instruction) Customizable User Preferences:  Provide programmatically determinable semantics that allows the user to make changes to their experience to meet their individual needs.  This includes: number types (e.g. phone, dates, currency), interruptions (e.g. aria live regions), abbreviations, definitions or accordions with additional instructions or expanded information,   —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.
lseeman commented 7 years ago

@jspellman sorry i pressed reply to the thread. i will try again: proposed wording SC1 : extra steps: When a process contains optional steps that are not required to complete the primary task, the user can control the trade off between function and simplification. with defined term "Primary task" defined as The core task the user has embarked on. ----------SC 2

Support personalization (minimum) : Contextual information and author settable properties of regions and critical features and important information are programatically determinable so that personalization is available.

with the ecseptions and definitions as above but.... define Contextual information: Semantics and tags that give meaning to the content such as context of elements; concept and role; relevance and information for simplification; position in a process

____sc3 Support personalization (all content): Contextual information and author settable properties of regions and elements are programatically determinable so that personalization is available.

Definitions and exceptions are the same as above

Does that address the mix

jmcsorle commented 7 years ago

The following pull requests have been created for this issue: Support Personalization (minimum) - https://github.com/w3c/wcag21/pull/125 Extra Steps - https://github.com/w3c/wcag21/pull/126 Support Personalization (all content) - https://github.com/w3c/wcag21/pull/127

awkawk commented 7 years ago

Updated the issue description to reflect the FPWD text and reopening issue.

FionaHolder commented 7 years ago

Are developers expected to just provide attributes / markup to make context clear to potentially support personalization features provided by a user agent, or are they also supposed to be including some form of personalization library within their application for the user to make configuration changes?

It's not immediately clear to me what developers are responsible for here. Is it like ARIA, where we add attributes and let user agents interpret those, or is there more work involved in user settings?

ayelet-seeman commented 7 years ago

Yes @FionaHolder it is like aria

ayelet-seeman commented 7 years ago

actually we now have a code injection script s that you can just say what things are in one file for your whole site, making it much easer then aria

ayelet-seeman commented 7 years ago

Some good news! the draft semantics is scheduled to be at first working draft in a month. Also we have a web extension for chrome that allows anyone to use it for free. we have some great early adopters including the BBC

mbgower commented 7 years ago

Is it like ARIA, where we add attributes and let user agents interpret those, or is there more work involved in user settings?

Yes @FionaHolder it is like aria... much easer then aria

Just to be clear, aria is a completed W3C recommendation with widespread browser support. Add it in according to the spec, and it should work on most browsers without further author intervention. Personalization is a draft standard with no (?) browser support. What the actual effort involved to satisfy this proposed SC will be is therefore difficult to gauge.

Aria 1.0's original purpose was to inject accessibility structure and functionality into inaccessible widgets. So, yes there was effort involved, but it was 'retrofitting' without altering the content or design.

My understanding is that personalization is/can be a different beast. It requires the author in many cases to have considered a number of different user requirements -- how would a plethora of users with different needs and preferences (visual, cognitive, reduced mobility, etc) want to modify a version of this content? The author then needs to address such considerations in the writing and design of the content, or as with some of the proposed COGA personalization attributes, to revisit completed content and overhaul it (manually or via future automated tools) so it can be transformed on user request. It then requires such content considerations to be properly tagged and structured in the content so that personalization can successfully transform it.

Feel free to correct where I am overstating the effort in what is being proposed. But I am equally concerned with underplaying the effort involved to support personalization.

ayelet-seeman commented 7 years ago

@mbgower @FionaHolder Mike - The following is completely incorrect " It requires the author in many cases to have considered a number of different user requirements" This is completely not the case. The author needs to understand nothing of these cases. They only add semantics about what the element is. It would be good to know where we miscommunication this so I can clarify that so others do not get wrong information as well (Off list please)

Secondly Wcag 2.0 became a standard in 2008. Aria was only a working draft then (I think first working draft) . ARIA only became a full standard in 2014. 6 years after wcag 2.0. The coga sematincs should be a working draft within the month (it has been an editors draft for years) and I understand aria is chartered on the same time line as wcag so they should be a full standard at the same time. In terms of support, at the time we had one browser support for aria - firefox - which was needed because it is abased on mapping for the accessibility api of the operating system or it does nothing. Coiga semantics does not need the accessibility api of the operating system, so we have no such restriction. However we have a free browser plug in so we have user support for anyone using chrome, we have implementation at the bbc, and smart md etc. so you could argue that support is similar good as we had for aria when wcag was at this stage. we also have IBM and Pearson working on it for different implementation. (we have a developer using the system to make vim keys and gamer implementations). If support is an issue then we need to clearly define what support is needed and make sure we have it. Finally personalization is the best enabler for accessibility for the huge diversity of cognitive disabilities - it enables addressing most of the coga sc in one SC. it is hugely important for the user.

lseeman commented 7 years ago

@mbgower Please contact me and not ayelet to go over where we miscommunication about how personlization works. As above, the author does not need to consider any user scenarios.

jnurthen commented 7 years ago

@ayelet-seeman The timeline for the User Context Properties Specification was based on a First Public Working Draft in November 2015. Based on this there was an anticipated Recommendation date of June 2018. If the FPWD were published today we would be on an 18 month delay which would take the recommendation date out to December 2019. (see https://www.w3.org/WAI/ARIA/project )

lseeman commented 7 years ago

James i think you are talking about a different specification. we will need to clarify this

All the best

Lisa

alastc commented 7 years ago

Things I noted from the call:

If it should align with ARIA & Name/role/value, then I think that the SC would need updating to be a sort of name/role/value 'plus'. I.e. if you have certain elements on a page, then use the appropriate semantics.

Personally I don't need to be persuaded about the importance, I need to know about the practicalities, i.e. how does it work?

So I have two other questions:

  1. Is the author responsible for adjusting the layout to allow for additional icons or other visual display changes? (Or am I getting mixed up with another SC?)
  2. Can the links to the resources for what the semantics are be updated? The links to Background research document & Semantics for adaptive interfaces are 404s.

Where did the list of COGA attributes come from? The example has aria-function & aria-importance, is there a list of these with their intended usage?

I think it would be best to have a set of aria attributes that are not (necessarily) disability specific, they should be a general set for describing the meaning of a website, so hopefully that is the intended direction?

alastc commented 7 years ago

(Replicating my survey response here)

I started thinking that editorially it could be simplified to: If there is a standardized method of exposing contextual information in the technology or the platform, then features available in that standard are programmatically determinable.

Reading up on the personalization semantics, it seems to ask: If you can use meta-data to describe something, do so.

In that vein, it is really 1.3.1 for personalisation, so in that context I would suggest:

Contextual Information that can be conveyed through meta-data is available for essential functionality and content.

The "can be conveyed" covers whether a standard is available or not, so that can be left to the techniques. Using "essential" to avoid the usability / process issue with terms like critical / important, and use an already defined term.

lseeman commented 7 years ago

alternitve wording - does this adress the issue

A version of the content is available such that one of the following is true: -supports the main role or tasks of the user interface where important information comes before other information; there are a maximum of 5 controls per screen; and controls have icons and visible text labels.

We can have a supportive techneque of having a more button which will allow people to support this by having a more/less button at triple a we could have both being requires

alastc commented 7 years ago

The main issue is being clear what is being asked of authors, this alternative wording changes things, but I'm struggling to understand why it is different from the previous version.

Specific issues now are:

Having two methods within the SC is confusing, can you please say which is the priority at level A?

If it is the meta-data aspect, that makes it an advance on 1.3.1 and I can see how that would work. In which case it would be something like:

Enable personalisation (minimum): Contextual information and author settable properties of essential features and information are programmatically determinable.

The rest of the understanding and techniques then refer to or include bits from the semantics spec.

If the first bullet is included in this SC, that cannot apply to all web content, so it either needs to be restricted by content type (which I don't think would be helpful), or put at AAA.

Also, answering the two questions from my previous comment above would really help move this along:

lseeman commented 7 years ago

Hi @alastc @jmcsorle The diffrence is that we have removed the dependecy on the new specification for context or on RDF which people were uncomfortable with. That is the whole point of it

Did you see the definition of important information?

How about

A version of the content is available such that one of the following is true:

(note the first bullet point is now inline with the wording of 2.4.2 Page Titled -so if this is too vauge so is 2.4.2) I need to double check the second bullet point as it misses some features. They may be included in other SC, but there is a risk we can not get them though.

RE:Contextual Information that can be conveyed through meta-data is available for essential functionality and content. - I do not think the term is metadate is typical if it is inline, maybe i am incorect. But how does the auther know when they are done? I changed the wording but I am not sure why it is any better and what issue does it solve? I am ok going with it if you think it solves something.

@jmcsorle can you fix the links ? In the mean time all our content is reachable from our main wiki page https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Main_Page

jmcsorle commented 7 years ago

Hi Alastair - these are very helpful comments. I will update the wording again and send out another note and I will fix the links.

lseeman commented 7 years ago

people think that personilazation is a new technology in the accessibility space. It has been successfuly used for years. In israel lots of big sites use it as the perfered way to meet accessibility requirments example:

https://www.cellcom.co.il/ https://cellcomtv.cellcom.co.il/#default https://www.ebox.co.il/ https://business.cellcom.co.il/#default http://www.elal.com/he/Israel/Pages/default.aspx
https://vacation.elal.co.il/ dev http://www.ikea.co.il/ testing https://www.shbn.co.il/ m.skinbinui.co.il
http://recruits.iaf.co.il/2455-he/IAF.aspx http://izkor.iaf.org.il/Templates/HomePage/HomePage.aspx http://m.iaf.org.il/7240-he/IAF.aspx
http://www.nblaw.com/ https://trade.psagot.co.il/#/join
http://testmobile.fattal.co.il/ dev https://www.lcweb-stg.co.il/ dev mba.biu.ac.il
https://www.xnes.co.il/ https://www.maccabitivi.co.il/ http://seiholding.com/ https://amacresearch.gatech.edu/
http://www.mla.ac.il/
https://www.ace.co.il/ cellcom.co.il

lseeman commented 7 years ago

when looking at the above examples it might be useful to know accessibility in hebrew is נגישות

Also the above examples include, telecom, healthcare, government, airline, education and businesses

I know of three Israeli companies providing accessibility though personlization of aria semantics and metadata. so this is widely implemented here

mbgower commented 7 years ago

people think that personilazation is a new technology in the accessibility space.

Can't speak for anyone else, but the question for me has never been whether there are techniques to support personalization and applications undertaking it now. If you look through my comments, you'll see that I have been advocating for capturing those techniques and incorporating them into existing relevant SCs since this issue was opened.

But the approach being taken has been to require the use of a draft standard, and the tactic seems to be to insist that this is the only way of incorporating personalization in WCAG. Given the years of examples you provide, this is obviously not the only means. The approach makes it very hard to meaningfully engage in this topic. In example, back in January, assurance was offered that when the standard was better developed most of the 2 dozen attributes will have default values. Six months later the latest draft shows that most do not have default values. The status of the standard, upon which this entire SC is currently built, continues to be one of the showstoppers. Additionally, all the other concerns I've listed (e.g., the fact the standard is targetted strictly at COGA) still apply, as far as I can tell.

patrickhlauke commented 7 years ago

the approach being taken has been to require the use of a draft standard, and the tactic seems to be to insist that this is the only way of incorporating personalization in WCAG. Given the years of examples you provide, this is obviously not the only means.

yes, i was about to post something along the same lines, but mike captured it much more succinctly here. this has been the main concern on this SC since the start, I believe.

lseeman commented 7 years ago

current wording being discussed "Contextual Information that can be conveyed through author settable properties is available for essential functionality and content. Essential functionality and content can be programmatically identified when they can be identified through author settable properties."

definitions:

Essential functionality and content can be defined as : the minimum functionality and content that is essential to fulfill the purpose or understand the topic of the content. The purpose or topic of the content should be identified in the page title.

Contextual information (already defined) semantics and tags that give meaning to the content, this includes: concept; role; relevance and information for simplification; information that clarifies the meaning; relationships to other elements; position in a process; process of which this element is a part

example test process: Identify minimum functionality and content that is essential to fulfill the purpose or understand the topic of the content. for the above: check that contextual information is programmatic determinable via auther setableble properties (if yes - pass) if not is it available though metadata (if yes - pass) if not is it implied though the dom or tag names (if yes - pass) can it be set though author settable properties (if not -pass . if yes fail)

repeat for if the essential functions have been identified

lseeman commented 7 years ago

@mbgower @detlevhfischer Some follow up: I did go though the specification for semantics and set as many defaults as I could. But it did not many sense ti have default which would probably be incorrect, So in many cases we did not add defaults. Basicly - we tried... Also we are establishing techniques using other specifications and methods such as APIP and microformats. i would appreciate some help with this.

lseeman commented 7 years ago

examples in microdata using wordnet

I am having trouble putting code in here so I am using brackets in place of "<"

(a itemprop="http://wordnetweb.princeton.edu/perl/webwn?s=homepage" ) Home (/a)

i need to check that this is valid code

lseeman commented 7 years ago

example with schema.org for idintifing the context

(button type="button" itemprop="http://schema.org/SendAction" >Send(/button>

eample for idtifing the key item

(a itemprop="mainEntityOfPage" href="http://example.com/article-1" >The full artical (/a>

lseeman commented 7 years ago

ims global data types apip : classification.purpose also adds context

Also from learning data schema

lseeman commented 7 years ago

another techneque Use rel such as rel="next" and rel="prev" links

jake-abma commented 7 years ago

Pseudo-assistive technology like the use of lay-overs are not the same thing as the text in the SC. There’s even a danger to promote such technologies as they are often laborious to handle, one-off on every site and provide for a means to pull out off the real problem for site owners which is making websites accessible / using standards to start with.

I also do see the need for these kind of personal adjustments from a user perspective but besides these technologies we also have the accessibility settings in the OS, the settings in a browser, plugins / extensions, different devices and assistive technology.

The lay-overs are just another fix op top possibility and the SC should be about a standard implementation.