|
| 1 | +# tpl.context_form.html |
| 2 | + |
| 3 | +## Requirements |
| 4 | + |
| 5 | +* For every input field there is a set of common parts that need to be represented. These |
| 6 | + should go into that template. |
| 7 | + * byline |
| 8 | + * error message |
| 9 | + * label (if possible, see below) |
| 10 | + * the actual input element from html |
| 11 | +* For every input that context should be as regular as possible: |
| 12 | + * to attach JS as easy as possible |
| 13 | + * to make styling via CSS as easy as possible |
| 14 | + * to make rendering code as simple as possible |
| 15 | + * to allow for easy maintenance of the template and all other code |
| 16 | + |
| 17 | +## Usage of fieldset for the context (and beyond...) |
| 18 | + |
| 19 | +* According to [0043886: missing legend element in fieldsets of KS forms](https://mantis.ilias.de/view.php?id=43886) |
| 20 | + `fieldset`s must have a `legend`. There is no specification that says so, but there |
| 21 | + [is a specification](https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions) |
| 22 | + that says: "Labels or instructions are provided when content requires user input.". It is |
| 23 | + arguable, if a `fieldset` is targeted by that requirement (as we define labels for all |
| 24 | + actual inputs), but the current usage of the fieldset is flagged by accessibiliy tools, |
| 25 | + such as IBM Equal Access Accessibility Checker anyway. Most probably this is caused by |
| 26 | + our kind of unorthodox usage, since `fieldsets` are mostly used group radio options or |
| 27 | + multiselect options in other contexts. |
| 28 | +* If we use `fieldset`s, we can _only_ use `legend`s to label it. A `label`s [`for` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/label#attributes) |
| 29 | + can only point to `labelable` elements, which `fieldset` sadly is not. |
| 30 | +* If we use `legend`s, we need to deal with specialized html-structures and hence CSS |
| 31 | + logic for any field that uses `fieldset`. Normally, we would put a `label` before the |
| 32 | + field that is labelled by it, for `fieldset`s the label (= `legend`) would be inside |
| 33 | + the field. We should avoid that. |
| 34 | +* We can use [aria roles for grouping](https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA17.html) |
| 35 | + instead and connect labels via [`aria-labelledby`](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-labelledby). |
| 36 | + But this does [not provide any other functionality that `for` does](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-labelledby#description), |
| 37 | + such as activating the input on click of the label. This has to be added via JavaScript. |
| 38 | + |
| 39 | +## Implementation |
| 40 | + |
| 41 | +* We should probably turn the renderer "inside out". By this we mean: normally we would |
| 42 | + switch on component type very early. But since we want to render a common context, we |
| 43 | + shall render that first and only switch for the inner parts. |
| 44 | +* We should probably use both, `for` and `aria-labelledby` for all inputs. `for` should |
| 45 | + override `aria-labelledby` if labelled element is `labelable`, else fallback to |
| 46 | + `aria-labelledby` will be used. Javascript then can be bound by looking into wether |
| 47 | + that `for` has bound or not. |
| 48 | +* "Disabled" need to be pushed down to the actual HTML-input all the time, especially |
| 49 | + for elements that could use `fieldsets` (but don't). |
| 50 | +* The error and the byline should be connected to the actual input inside the context |
| 51 | + container via `aria-describedby`. We can use more than one id for the label |
| 52 | + (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-describedby). |
| 53 | + if both thingies exist. We should probably start with the error then, just like in |
| 54 | + the HTML. Both, hence, need an id. |
0 commit comments