NOTE: In progress - will update after testing the current state and noting what is working and not. Need to also set an accessibility goal (ie. AA/AA to help decide what is required and what is nice to have)
==Background
We would like to meet Level A as defined in WCAG 2.0, [[ https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0#adaptable | Guideline 1.3 Adaptable ]], with a particular focus on 1.3.1 Info and Relationships.
As a screen reader user, I want to understand
- which types of content exist within the modal and have access to a clear overview of eachthe structure, with easy navigation between the main areas
- which individual elements exist within each area and what their roles and labels are
- how to interact with them
To do this, all elements need a clear role, name and description. There should also be a way to get an overview (by
==Requirements (DRAFT)his is a parent ticket to track the accessibility tickets to fix the issues related to the above goals after basic testing with VoiceOver.
-----
NOTE: Previous notes - delete after other tickets are created and information is integrated
[] Users are able to get an overview of the content and areas within the modal using landmarks. All perceivable content within the modal should belong to a landmark region with a semantically meaningful role. The modal has two main areas:
- [[ https://www.w3.org/TR/wai-aria-1.2/#main | Main landmark ]] for right side content where parameter values are added
>> sub-section for the fields with a form landmark?
- [[ https://www.w3.org/TR/wai-aria-1.2/#complementary | Complementary landmark]] for sidebar, which then has sub-areas for the sections within. If an area begins with a heading element (e.g. h1-h6) it can be used as the label for the area using the `aria-labelledby` attribute.
- Template search has a search landmark
- List of parameters is missing a title, so it needs a label and [[ https://www.w3.org/TR/wai-aria-1.2/#region | Region landmark ]]
[] Individual elements should be understandable
- Checkboxes have checkbox role
- Names are clear and descriptions give additional information about how to interact with an item using keyboard navigation
- Parameter fields should use `aria-labelledby` for the title and should use `aria-describedby` using an id. (More/less are ignored. If the screen reader chooses to listen to the description, the whole description is read.)
-----
Previous notes to consider:
* When I, as a screenreader user, navigate the right content area of the template dialog, I want to understand where I am, and what the meaning of the elements is. Especially: Template names and parameter names should not just be read as they are, but announced as e.g. "template 'infobox river'" or "edit parameters of 'infobox river'". Individual parameters might be announced as e.g. "(parameter) 'name' of/in 'infobox river'". **(TBD)**
* When I navigate the sidebar, every element should be properly announced. Most notably: The list of parameter (being a single tab target) must be announced with e.g. "parameters available for 'infobox river', use cursor keys and space to toggle". **(TBD)**
* When I press enter in the sidebar, the focus jumps to the corresponding template header or individual parameter on the right. The first thing the screenreader should read is not necessarily the name of the template or parameter. That would be redundant, assuming this was the last thing that was read before leaving the sidebar. Still I, as a screenreader user, want to understand where I am. The screenreader should announce these positions somehow, e.g. "edit parameters of 'infobox river'" (note this was originally part of T285323). **(TBD)**
* ~~Required parameters are represented as disabled checkboxes in the sidebar. Make sure screenreader users can understand this. Possibly remove the checkbox. Possibly make use of OO.ui.mixin.RequiredElement (sets `aria-required`, see https://gerrit.wikimedia.org/r/711145 ).~~ From https://stackoverflow.com/q/34300154#comment85584639_34300154: //"For checkboxes, regardless if checked or not a value is passed to through the form. If you want to communicate that the user must check a checkbox to proceed / submit, then such a message should be associated through us of the aria-describedby attribute pointing to a text container (via that container's ID attribute)."//