RE: Musings on Functional Outcomes, granularity

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<mailto: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