Re: CFC - WCAG 2.2 Page break navigation normative text

+1

** katie **

*Katie Haritos-Shea*
*Principal ICT Accessibility Architect*


*Senior Product Manager/Compliance/Accessibility **SME*
*, **Core Merchant Framework UX, Clover*


*W3C Advisory Committee Member and Representative for Knowbility *


*WCAG/Section 508/ADA/AODA/QA/FinServ/FinTech/Privacy,* *IAAP CPACC+WAS = *
*CPWA* <http://www.accessibilityassociation.org/cpwacertificants>

*Cell: **703-371-5545 <703-371-5545>** |* *ryladog@gmail.com
<ryladog@gmail.com>* *| **Seneca, SC **|* *LinkedIn Profile
<http://www.linkedin.com/in/katieharitosshea/>*

People may forget exactly what it was that you said or did, but they will
never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to
dictate where we are going.






On Fri, Jun 24, 2022 at 1:20 PM Shawn Lauriat <lauriat@google.com> wrote:

> -1
>
> For the all same reasons Wilco articulated.
>
> On Fri, Jun 24, 2022 at 10:42 AM Wilco Fiers <wilco.fiers@deque.com>
> wrote:
>
>> -1
>>
>> In my opinion the user need for the success criterion as written has not
>> been sufficiently established. While it is certainly true that for example,
>> students need to be able to navigate to specific pages in digital text
>> books, it doesn’t necessarily follow that every web page containing page
>> break indicators poses a significant accessibility barrier unless page
>> break navigation is added. For example, if the web page has only one or two
>> page break locators.
>>
>> There is also no allowance for alternative forms of navigation within the
>> page, for example navigating a page by headings through a table of contents
>> could address the same user need. In that way the success criterion is
>> overly prescriptive. Unlike for example 2.4.5 Multiple Ways and 2.4.1
>> Bypass Blocks, which allow for different solutions.
>>
>> Lastly, I believe this success criterion is a poor fit for WCAG 2.2. It
>> is written in such a way that it can only be applied to EPUB, regardless of
>> the much broader user need for inner-page navigation for large documents.
>> WCAG 2.2 is designed as a technology agnostic standard. Success criteria
>> should not be constrained to apply to only one technology.
>>
>>
>>
>>
>> On Wed, Jun 22, 2022 at 5:41 PM Alastair Campbell <acampbell@nomensa.com>
>> wrote:
>>
>>> Call For Consensus — ends Monday June 27th at midday Boston time.
>>>
>>>
>>>
>>> The Working Group has previously discussed the WCAG 2.2 SC Page break
>>> navigation and the Normative text needs to be approved by CFC.
>>>
>>>
>>>
>>> It can be previewed in the editor’s draft:
>>>
>>> https://w3c.github.io/wcag/guidelines/22/#page-break-navigation
>>>
>>>
>>>
>>> The SC was last discussed in a meeting May 17th:
>>>
>>> https://www.w3.org/2022/05/17-ag-minutes#item05
>>>
>>>
>>>
>>> The change history is here:
>>>
>>>
>>> https://github.com/w3c/wcag/commits/main/guidelines/sc/22/page-break-navigation.html
>>>
>>>
>>> https://github.com/w3c/wcag/commits/e2e4cda3667e37a8a12ceaf0dd81f7c5595195e8/guidelines/sc/22/fixed-reference-points.html?browsing_rename_history=true&new_path=guidelines/sc/22/page-break-navigation.html&original_branch=main
>>>
>>>
>>>
>>> The survey is available here:
>>>
>>> https://www.w3.org/2002/09/wbs/35422/wcag22-page-break-nav/
>>>
>>>
>>>
>>> The github issues are listed here:
>>>
>>> https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%222.4.13+Page+break+locators%22+
>>>
>>>
>>> (There is 1 open, related to an understanding content update.)
>>>
>>>
>>>
>>> If you have concerns about this proposed consensus position that have
>>> not been discussed already and feel that those concerns result in you “not
>>> being able to live with” this decision, please let the group know before
>>> the CfC deadline.
>>>
>>>
>>>
>>> Kind regards,
>>>
>>> -Alastair
>>>
>>> --
>>>
>>>
>>>
>>> @alastc / www.nomensa.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> *Wilco Fiers*
>> Axe-core & Axe-linter product owner - WCAG 3 Project Manager -
>> Facilitator ACT Task Force
>>
>>
>>

Received on Friday, 24 June 2022 20:16:00 UTC