- From: jake abma <jake.abma@gmail.com>
- Date: Wed, 9 Sep 2020 18:30:15 +0200
- To: Detlev Fischer <detlev.fischer@testkreis.de>
- Cc: WCAG list <w3c-wai-gl@w3.org>
- Message-ID: <CAMpCG4EKFjgzSK5JrqxhO7JBPDhWggVcJbHkCRTFvp2NaOHf0A@mail.gmail.com>
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 > > >
Received on Wednesday, 9 September 2020 16:30:40 UTC