Re: Musings on Functional Outcomes, granularity

exactly, and a FO mentioning Heading are required OR you fail, don't fit
the possibility of other structural solutions, this is why a must for using
heading is also not a A or AA I think.
Example: you have a page for a big form with some tables and you use
properly Captions for the tables and Legends for the fieldsets, is this a
fail because you do not use Headings although they might "look like
Headings"?

Op wo 9 sep. 2020 om 18:36 schreef Jonathan Avila <jon.avila@levelaccess.com
>:

> I agree we can’t use headings as a normative criteria as some technologies
> won’t have the concept of headings – so structure and other concepts are
> needed.  This is why we ended up with SC 1.3.1, etc. in WCAG 2 to make
> things more technology neutral.  The challenge with WCAG 2.0 was the
> connection between techniques and the criteria and the ambiguity of
> sufficient techniques and limited number of failure techniques  etc.
>
>
>
> Jonathan
>
>
>
> *From:* jake abma <jake.abma@gmail.com>
> *Sent:* Wednesday, September 9, 2020 12:30 PM
> *To:* Detlev Fischer <detlev.fischer@testkreis.de>
> *Cc:* WCAG list <w3c-wai-gl@w3.org>
> *Subject:* Re: Musings on Functional Outcomes, granularity
>
>
>
> *CAUTION:* This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Good point Detlev, the semantic approach seems to be copied over and over
> again for all elements who need semantics.
>
> I've mentioned this before, also as you can navigate input fields, links,
> lists etc. etc.and use other elements for structure besides Headings.
>
> Other properties have not been part of headings but do apply to headings,
> like contrast, plain language, text spacing etc.etc.
>
> Also blending a role (heading) with levels (properties) get you into
> trouble as mixing will end up with too many variables (have spreadsheets to
> prove the complexity when testing)
>
>
>
> My conclusion in the Silver group was that a Heading guideline seemed too
> specific and if all others will also be guidelines, things will 'bloat' too
> much (too many guidelines are needed with same / duplicate content)
>
> The functional needs and outcomes are not specific but generic often so a
> more generic FO seems more appropriate to look at.
>
> We had of course 4.1.2.and 1.3.1 (but that approach was not even so bad..)
> and I played with the idea of having property like guidelines applying to
> others (like navigate, contrast, and plain language for a Heading guideline.
>
>
>
> In the end all the others need to be scored also and if they are under
> other guidelines and the functional outcomes are not consistent, the
> scoring normalization will be hard if not impossible / not reasonable.
>
>
>
> Creating all Methods for all those FO also seems like we need 1000+
> methods which may not be feasible.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Op wo 9 sep. 2020 om 16:26 schreef Detlev Fischer <
> detlev.fischer@testkreis.de>:
>
> If I take Jakes examples for 'Semantic Structure', I guess the
> associated Functional Outcomes (which ones do we need?) should be
> informed by looking whether different tests are needed to verify whether
> the FO is achieved. Let's try it for the three FOs listed by Jake:
>
> Am 07.09.2020 um 09:46 schrieb jake abma:
> >
> > "Provides semantic structure so can convey a sense of hierarchy"
> Would check whether visual headings are marked up by h1-h6 or ARIA equiv.
> Would check whether the  mark-up levels convey the hierarchy (this may
> be the place to tolerate skipped levels if the overall hierarchy is
> correct)
> > "Provides semantic structure so users can navigate"
> Seems partly covered in "sense of hierarchy", e.g. in the case of
> invisible headings to bypass blocks, or in fact for content navigation
> of documents (say, Screenreader command "2" will go to next section when
> all correctly marked up with h2)
> Would check whether structural parts like header, nav, main, footer are
> marked up so they can be reached via landmark navigation
> > "Provides semantic structure so users can locate"
> Same as above? Or it might add checking whether stuctural elements are
> not only marked up also meaningfully named for differentiation
> Might also check whether particular types of content can be located,
> say, if search is defined as role (but may still pass content where it
> is not marked up thus, so graded rating will be beneficial here)
>
> So we see that the same tests contribute to different FOs, which may not
> be not a bad thing.
>
> The question that arises is whether 'semantic structure' should also
> encompass things other than headings and structural page sections:
> - tables have a simple hioerarchy of th / td (or even leves of th)
> - fieldset/legend -> label may be conisdered a hierarchy
> - think tapanels, menus, trees, etc...
>
> Are we going to create other FOs for different semantic structures so we
> can pin more specific methods to these and avoid the kitchen-sink
> problem of SC 1.3.1?
>
> So I am really uncertain how the order of things (with its differences
> across technologies) will be best reflected in the order of FO, how
> fine-grained FO should be to be most useful, and if and how FOs can be
> kept technology-independent in the way current SCs strive to be (some of
> them not so successfully).
>
> Detlev
>
> --
> Detlev Fischer
> DIAS GmbH
> (Testkreis is now part of DIAS GmbH)
>
> Mobil +49 (0)157 57 57 57 45
>
> http://www.dias.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
>