Re: CFC: Change of Content SC

Hi David,
>>I can see the rational for added content to components in 4.1.2, but the 1.3.1 >>interpretation would require the new content to be visually styled in some
>>specific way. The content appears visually and that in itself is what catches the >>attention of the sighted person, not the way it is styled.

Sailesh: SC 1.3.1 covers info relationships conveyed by presentation
which covers both positioning and styling.
A global error message positioned above the form or at the start of
main content when the form is pretty much the main content conveys a
relationship to the task being attempted. Styling will enhance its
visibility.
A field level message next to a form control may visually convey a
similar relationship.
Merely including markup to pass 1.3.1 will not by itself help screen
readers detect the presence of newly added content ... one needs to
set focus or use ARIA (role, aria-live etc.) or the content needs to
be in the reading / tab flow.

>>I discovered how difficult it is to introduce a failure to WCAG 2 for techniques or tasks that did not exist when WCAG 2 was released.
Sailesh: I do not see the significance of this to the discussion on hand.
In any case, one cannot fail an SC if a particular technique
(landmarks) is not employed. Landmarks are useful only for users of
ARIA-aware-At mainly. Other mechanisms to expose page structure may be
present on the page.

On the other hand many techniques that are sufficient to pass an SC
were written up only after WCAG 2.0 was released (including ARIA-11
which you authored chiefly amongst others and  3-4 ARIA techniques
that I wrote up in 2014).

>>I doubt there will be a statement such as that forthcoming for the reasons above.
Sailesh: I do not see any reasoning in your last message prior to that
comment by you. Am I missing something?

Thanks and best wishes,
Sailesh Panchang


On 5/31/17, David MacDonald <david100@sympatico.ca> wrote:
>>  ...  applying the text of the SC read with the definitions to situations
> / content generated using  newer programming techniques. WCAG 2 is not
> technology centric and is written in a manner that it will endure.
>
> I can see the rational for added content to components in 4.1.2, but the
> 1.3.1 interpretation would require the new content to be visually styled in
> some specific way. The content appears visually and that in itself is what
> catches the attention of the sighted person, not the way it is styled.
> Mapping that to 1.3.1 is problematic, I would say, but I'd be glad to hear
> from others if they see it that way.
>
> However, regardless, I discovered how difficult it is to introduce a
> failure to WCAG 2 for techniques or tasks that did not exist when WCAG 2
> was released. I filed an issue proposing a failure of 1.3.1 for not adding
> landmarks where there is a visually defined header, navigation, main
> content and footer, and area for complementary information. Trying
> introduce this failure cost us two meetings and stalled completely and went
> nowhere. https://github.com/w3c/wcag/issues/173
>
>> I would like to see a categorical statement that says such situations
>> never
> existed at the time of writing WCAG 2.0 or  they were not contemplated by
> WCAG 2.0  as there were no AT-supported techniques to address them at that
> time ... or along those lines.
>
> I doubt there will be a statement such as that forthcoming for the reasons
> above.
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> 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>
>
> On Wed, May 31, 2017 at 2:19 PM, Sailesh Panchang <
> sailesh.panchang@deque.com> wrote:
>
>> David,
>> I will be happy to discover  where my interpretation transgresses
>> normative text of WCAG 2.0.
>> I am merely applying the text of the SC read with the definitions  to
>> situations / content generated using  newer programming techniques.
>> Nothing that is contrived or liberal here as you like to characterize
>> it.
>> WCAG 2 is not technology centric and is written in a manner that it
>> will endure. So one has to read  the guidelines and see how existing
>> SCs can be applied to situations one comes across ... just like one
>> applies WCAG 2.0 to mobile content although the guidelines or
>> Understanding docs make little or no reference to mobile technologies.
>> I do not think a new SC is needed for newly added content  as
>> discussed in the proposed SC.
>> I would like to see a categorical statement that says such situations
>> never existed at the time of writing WCAG 2.0 or  they were not
>> contemplated by WCAG 2.0  as there were no AT-supported techniques to
>> address them at that time ... or along those lines.
>>
>> If newly added content  is not presented in a manner that it catches
>> attention visually, then all users are at a loss and are unaware of
>> what happendd based on  user action.
>> Thanks and best wishes,
>> Sailesh
>>
>>
>> On 5/31/17, David MacDonald <david100@sympatico.ca> wrote:
>> >> Likewise if something is styled distinctly so as to arrest attention
>> >> visually
>> > it functions like an alert or status message. That is the
>> > ​
>> > info-relation  being conveyed via presentation but if it lacks  markup
>> > to
>> > convey that it fails 1.3.1 as well.
>> >
>> > You and I have discussed this fairly extensively off line. I think this
>> is
>> > a fairly liberal interpretation of 1.3.1. The scenario is not a
>> > standard
>> > violation of 2.0 cited by most of us in this field. Some may say it is
>> > somewhat contrived although I can understand your rationale, and I
>> wouldn't
>> > contradict it if a report like this came across my desk. However, I
>> > would
>> > raise my eyebrows because I wouldn't say these updates often "arrest
>> > attention visually".
>> >
>> >> which needs to be clarified in Understanding 4.1.2 /1.3.1.
>> >
>> > I think by saying this, you understand that this is not the common
>> > interpretation of this SC by people in this field, nor is it clear in
>> > our
>> > current 2.0, and having been on almost all of the calls that resulted
>> > in
>> > those SCs, I can say I don't remember any discussion of notification of
>> > change of content being intended in 1.3.1. It may be difficult to
>> introduce
>> > "qualifying" statements that have the effect of changing the way
>> > accessibility professionals interpret the SC 9 years after the release
>> > of
>> > WCAG 2. I doubt it would gain consensus by the group. It would
>> > certainly
>> > use up a lot of precious time, which the group can't afford, given it's
>> > self imposed date of August to have all the new work laid out in rough.
>> > I've
>> > not seen any success in trying to introduce qualifying statements to
>> WCAG 2
>> > that cause a change in interpretation.
>> >
>> > The proposed SC has broad consensus. Can you live with it?
>> >
>> >
>> >
>> > Cheers,
>> > David MacDonald
>> >
>> >
>> >
>> > *Can**Adapt* *Solutions Inc.*
>> >
>> > Tel:  613.235.4902
>> >
>> > 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>
>> >
>> > On Tue, May 30, 2017 at 9:40 PM, Sailesh Panchang <
>> > sailesh.panchang@deque.com> wrote:
>> >
>> >> Hi David,
>> >>
>> >> When something looks and functions like a heading  but is not marked
>> >> up as one,  it triggers 1.3.1
>> >> Likewise if something is styled distinctly so as to arrest attention
>> >> visually it functions like an alert or status message. That is the
>> >> info-relation  being conveyed via presentation but if it lacks  markup
>> >> to convey that it fails 1.3.1 as well.
>> >>
>> >> Is the counter that is incremented on adding to cart or the alert /
>> >> status message displayed on activating a button not "a part of the
>> >> content that is perceived by users as a single control for a distinct
>> >> function"?
>> >>
>> >> True, the content is often not positioned  adjacent to the trigger
>> >> element, that is why it is styled distinctly.
>> >>
>> >> A form is a composite UIC and the form level error message relates to
>> >> the form in toto and is content generated by script for that component
>> >> as part of a distinct function of form submission.
>> >> The above is based solely on an interpretation  of the normative  text
>> >> of WCAG 2.0 which needs to be clarified in Understanding 4.1.2 /
>> >> 1.3.1.
>> >>
>> >> By the way, one can use role=alert for a global alert message and that
>> >> is the equivalent of aria-live=assertive. If one wishes to use
>> >> 'polite' instead, that is not a deal breaker.  It is a technique that
>> >> supports existing SCs.
>> >> Best wishes,
>> >> Sailesh
>> >>
>> >>
>> >> On 5/30/17, David MacDonald <david100@sympatico.ca> wrote:
>> >> >> What this new content is missing is a corresponding role and is
>> >> >> covered
>> >> > by SC 4.1.2 even now.
>> >> >
>> >> > 4.1.2 covers interactive components. This is wider, covering all
>> >> > content,
>> >> > and simpler at the same time. Requiring a summary message like the
>> >> examples
>> >> > in the Understanding. The Understanding can also explain those
>> >> > things
>> >> above
>> >> > the current requirements of 4.1.2
>> >> >
>> >> >> Exception #1 to proposed SC  suggests the new content could be
>> >> associated
>> >> > with the trigger element. This SC would be triggered even when an
>> error
>> >> > message is placed next to a failed field and is associated say via
>> >> > aria-describedby and focus is placed on the field when the form is
>> >> > presented with errors...
>> >> > because the error message is not associated with the submit button.
>> >> >
>> >> > That is a programmatic association and is sufficient
>> >> >
>> >> >> I am assuming this form has no global  message above the form like
>> >> >> 3
>> >> >> errors
>> >> > present / form submission failed.
>> >> >
>> >> > The primary technique would be for an announcement that there are "x
>> >> errors
>> >> > on the page"
>> >> >
>> >> >> A global message needs role=alert or aria-live=assertive.
>> >> >
>> >> > Yes that would be a technique, however I would not recommend
>> >> > "assertive"
>> >> > unless a house is burning down. better to use polite as per the aria
>> >> > spec
>> >> >
>> >> >> Change in count of cart or  remaining characters in a text area is
>> >> >> updated
>> >> > in an element that needs role=status with aria-live=polite.
>> >> >
>> >> > Yes
>> >> >
>> >> > Cheers,
>> >> > David MacDonald
>> >> >
>> >> >
>> >> >
>> >> > *Can**Adapt* *Solutions Inc.*
>> >> >
>> >> > Tel:  613.235.4902
>> >> >
>> >> > 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>
>> >> >
>> >> > On Tue, May 30, 2017 at 5:10 PM, David MacDonald
>> >> > <david100@sympatico.ca>
>> >> > wrote:
>> >> >
>> >> >> >  ?? Do we have techniques for doing this?
>> >> >>
>> >> >> Yes, in all major technologies.
>> >> >>
>> >> >> >> For example in a game or simulation - there will continual
>> >> >> >> changes
>> >> >> >> of
>> >> >> content.   There is no exception for this  — so is there a
>> >> >> technique
>> >> that
>> >> >> should be used in these situations  to indicate that there are
>> >> >> continuously
>> >> >> changing content?
>> >> >>
>> >> >> We can place a note on the Draft: "The working group is seeking
>> >> >> input
>> >> >> to
>> >> >> account for situations where there is frequent, or constant
>> updating."
>> >> >>
>> >> >> >> Or is this ONLY supposed to apply to content that changes in
>> >> >> >> response
>> >> >> to a user action.
>> >> >>
>> >> >> It applies to all changes to the content currently. It could be
>> >> >> narrowed
>> >> >> for user initiated changes but the general feeling is that it
>> >> >> should
>> >> >> include all changes to content that are part of the primary purpose
>> of
>> >> >> the
>> >> >> page.
>> >> >>
>> >> >> >> If you DON’T mean changes due to user action — then for dynamic
>> >> >> >> content
>> >> >> (constantly changing) content is a simple notice someplace that
>> >> >> says
>> >> that
>> >> >> the page has continually changing content sufficient?  or would the
>> >> >> page
>> >> >> need to stream a constant flow of notifications through some
>> mechanism
>> >> >> that
>> >> >> is supported by AT?
>> >> >>
>> >> >> We could provide something like that. However, I would like to hear
>> >> >> what
>> >> >> the public has to say. There was an exception for over 5
>> notifications
>> >> >> a
>> >> >> minute, but it was dropped. Your language might be better. We want
>> >> >> to
>> >> >> ensure however there is not an exemption for things like chat
>> widgets,
>> >> >> where a ping that a comment was posted is key to having a fluent
>> >> >> conversation. This is the usual behavipur anyway of chat programs.
>> >> >>
>> >> >>
>> >> >> Cheers,
>> >> >> David MacDonald
>> >> >>
>> >> >>
>> >> >>
>> >> >> *Can**Adapt* *Solutions Inc.*
>> >> >>
>> >> >> Tel:  613.235.4902 <(613)%20235-4902>
>> >> >>
>> >> >> 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>
>> >> >>
>> >> >> On Tue, May 30, 2017 at 4:39 PM, Detlev Fischer <
>> >> >> detlev.fischer@testkreis.de> wrote:
>> >> >>
>> >> >>> +1
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >>
>> >
>>
>

Received on Thursday, 1 June 2017 01:18:44 UTC