From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18878 invoked from network); 22 Jun 2022 19:15:39 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 22 Jun 2022 19:15:39 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 5ba99373 for ; Wed, 22 Jun 2022 14:15:37 -0500 (EST) Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 932c79f1 for ; Wed, 22 Jun 2022 14:15:36 -0500 (EST) Received: from hekate.asta.kit.edu ([2a00:1398:5:f401::77]) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (envelope-from ) id 1o45p7-00Cnkd-79; Wed, 22 Jun 2022 21:15:35 +0200 Received: from login-1.asta.kit.edu ([2a00:1398:5:f400::72]) by hekate.asta.kit.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1o45p7-0063jE-0z; Wed, 22 Jun 2022 21:15:33 +0200 Received: from schwarze by login-1.asta.kit.edu with local (Exim 4.92) (envelope-from ) id 1o45p7-0003Ck-DX; Wed, 22 Jun 2022 21:15:33 +0200 Date: Wed, 22 Jun 2022 21:15:33 +0200 From: Ingo Schwarze To: Anna Cc: tech@mandoc.bsd.lv Subject: Re: [PATCH 0/8] Make generated HTML more accessible Message-ID: References: <20220621122749.11417-1-cyber@sysrq.in> X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220621122749.11417-1-cyber@sysrq.in> Hello Anna, thank you for sending your patches. I agree that accessibility is an important goal. Anna wrote on Tue, Jun 21, 2022 at 05:27:41PM +0500: > For reference: > * https://www.w3.org/TR/dpub-aria-1.1/ > * https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ These documents are extremely long (which is unfortunately the case for many other W3C documents too, and which is a common effect of design by committee in general). An unfortunate consequence is that i will have to read them selectively, and even that may take time. Three other goals of the mandoc project, in addition to accessibility, are (1) simplicity, (2) standard conformance, and (3) consistency. There are more goals, like correctness, robustness, security etc., but those matter less in the present context. These goals have a number fo implications: - (1) simplicity means that i do not want to add redundant or unnecessarily long markup. For example, i would not want to add ARIA properties if the HTML element used already implies the role, or can be changed to imply the role. As another example, when adding a new wrapper element for ARIA purposes, i would want to check whether the immediately surrounding, adjacent, or contained elements can be simplified. From a brief review, i suspect that your patches are already quite good in this respect, but i want to check such aspects for every change. - (2) standard conformance is in particular related to https://www.w3.org/TR/wai-aria-1.1/ section 1.4 Co-Evolution. I want both HTML elements and properties and ARIA properties used as standardized, but i fear there may still be places where elements are abused and more standard-conforming elements can be chosen. So whenever changing an element, i want to check the immediate vicinity for conformance. - (3) consistency implies that if one technique is chosen - respecting simplicity and conformance as described above - at one place, then it should be used throughout for the respective mdoc(7) or man(7) macro or for the respective HTML element. This is particularly important for languages that are as large as HTML, CSS, and ARIA: They usually provide several different ways to achieve a similar effect, and unless consistency is taken very seriously, markup chaos typically ensues. For these reasons, i never accept patch series. Instead, i will consider each patch separately. Let's see how that goes. One final question: Do you have a good way for testing? Is there a difference in the diff in the amount of effort for: 1. testing an uncommitted diff 2. testing a committed diff 3. testing a diff deployed to man.openbsd.org ? Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv