Re: CFC - Add Findable Help to WCAG 2.2 draft

It all depends on how 'well' a SPA is implemented.

In a nutshell a SPA fetches a single HTML page which then acts as a 
container which may include a header and footer, say, that do not much 
change as the user interacts. As the user navigates a round the app 
JavaScript is used to fetch data and update the page contents the user 
sees, mostly inside the wrapper.

So

 >   * The page title is the same for all “pages” of the single page web app

Yes if the SPA code does not update it - ditto the URL seen in the 
address bar. Better SPAs maintain both has key pieces of web information 
for users.

 >   * And if the help information is not located in a place that persists
 >     regardless of which portion of the single page web app the person is
 >     on,

yes, if it's not on the 'wrapper' part.

So I can't recall the original context but the user experience of hep 
might be might be identical - good or bad. The problem occurs when for 
our definitions we tie the concept of a 'page' to a browser HTML page 
fetch - they do not apply to SPAs. Rather SPAs perform data fetches and 
update part of the screen contents. That's a key reasons the concept of 
Page is now problematical.

Steve

On 16/06/2020 15:09, Delisi, Jennie (MNIT) wrote:
> In regards to the single page web apps (#2), this came up in a 
> discussion with Steve Lee as we were working through where else the 
> issue may need to be solved. I believe that for some:
> 
>   * The page title is the same for all “pages” of the single page web app
>   * And if the help information is not located in a place that persists
>     regardless of which portion of the single page web app the person is
>     on, 
> 
> without this being specifically called out, this would exclude many 
> single page web apps from being required to follow this proposed SC.
> 
> Yes, for #3, there was discussion by the AG group about the need to 
> ensure that PDFs were not included in this proposed SC so this was the 
> solution used to achieve this.
> 
> I will miss the first hour of the AG call today, but will join the 2^nd 
> hour.
> 
> Jennie
> 
> *Jennie Delisi, MA, CPWA*
> 
> Accessibility Analyst | Office of Accessibility
> 
> *Minnesota IT Services*|*Partners in Performance*
> 
> 658 Cedar Street
> 
> St. Paul, MN, 55155
> 
> O: 651-201-1135
> 
> /Information Technology for Minnesota Government/ | mn.gov/mnit 
> <http://mn.gov/mnit>
> 
> Minnesota IT Services Logo
> 
> Facebook logo <https://www.facebook.com/MN.ITServices>LinkedIn logo 
> <https://www.linkedin.com/company/minnesota-it-services/>Twitter logo 
> <https://twitter.com/mnit_services>
> 
> *From:* Alastair Campbell <acampbell@nomensa.com>
> *Sent:* Tuesday, June 16, 2020 8:40 AM
> *To:* Andrew Kirkpatrick <akirkpat@adobe.com>
> *Cc:* WCAG <w3c-wai-gl@w3.org>
> *Subject:* RE: CFC - Add Findable Help to WCAG 2.2 draft
> 
>  
> 
> *This message may be from an external email source.*
> 
> Do not select links or open attachments unless verified. Report all 
> suspicious emails to Minnesota IT Services Security Operations Center.
> 
> ------------------------------------------------------------------------
> 
> Hi Andrew,
> 
>  1. The 4^th bullet seems incomplete…
> 
> Indeed, we caught that at the last minute, if you look at the preview it 
> should say:
> 
> “A fully automated contact mechanism"
> 
> https://raw.githack.com/w3c/wcag/wcag22-findable-help/understanding/22/findable-help.html 
> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githack.com%2Fw3c%2Fwcag%2Fwcag22-findable-help%2Funderstanding%2F22%2Ffindable-help.html&data=02%7C01%7Cjennie.delisi%40state.mn.us%7C2072fc618d4f4055435208d811fad6c5%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C637279116345597049&sdata=mbrZPCYnk2wCyJsX6OEY17sHrifkaKyR7Af99oEMml0%3D&reserved=0>
> 
> I think you must have loaded the previous version, possibly cached.
> 
>  2. I agree with Wilco’s point about SPA’s but more to the point, are we
>     finding SPA’s that have help and that move it around to different
>     locations?
> 
> It was raised by the COGA TF as something to include, I don’t know the 
> examples off hand, we can ask. It does occur to me it might be easier to 
> consider an SPA as a ‘set of web pages’ than define something new.
> 
>  3. I don’t understand (or have forgotten) why we are concerned with the
>     blocks of repeated content in a set of web pages. 
> 
> I think this was to avoid things like PDFs needing to include help, it 
> was a proxy for ‘more than a one page site or PDF’.
> 
> However, perhaps that was from before the switch to using [if it has / 
> then locate it], so it might not be needed.
> 
>  4. For the location, why not use the “same relative order” as this
>     worked for 3.2.3 Consistent Navigation?
> 
> It would need to be relative /to/ something. The other SC is relative to 
> navigation mechanisms, I assume this would be relative to other page 
> content. Otherwise it reads as relative to each mechanism.
> 
> E.g. “For any set of web pages 
> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG21%2F%23dfn-set-of-web-pages&data=02%7C01%7Cjennie.delisi%40state.mn.us%7C2072fc618d4f4055435208d811fad6c5%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C637279116345597049&sdata=qxeV%2FXc5AlAlvADNSBEb4oVbKlBlv6NyGXUB6uin8c4%3D&reserved=0>, 
> if one of the following is available, then at least one of the following 
> is provided in the same relative orderon each page:…”
> 
> I don’t think it reads as well, but if that helps…
> 
> -Alastair
>

Received on Tuesday, 16 June 2020 14:21:20 UTC