Health Measures
Part of Community participation and accessibility
Designing a community for members using assistive technology
Check joining, reading, posting and reporting tasks with keyboard, screen reader and other access routes, then record barriers for repair.
Design around the tasks members need to complete: join, find a discussion, read it, contribute and report a problem. Check each task with the controls and permissions members will use. Clear writing helps, but an unlabelled button or inaccessible posting form can still stop participation.
List tasks and recovery paths
Include common paths and what happens when they fail. A member might arrive through an invitation, search for an answer, reply to a topic, edit a mistake or report harmful content. Record where each path begins, what completion looks like and what the member sees after an error.
Use the intended member role, including restricted areas. An administrator may see different controls. Check the mobile route where relevant.
If a hosted provider supplies part of the interface, record which problems the community team can change and which need a provider fix or different configuration. Do not assume a feature works in a particular plan or setup without checking it.
Check navigation and reading
Screen reader users may navigate by headings and control names. A person using a screen magnifier may see only a small part of a page. Others may use speech input, switches or a keyboard. These patterns differ, so inspect the task instead of treating one device as a stand-in for all members.
Use headings that describe the content below them and follow a meaningful order. Give links and buttons names that identify their purpose. Make topic choices understandable without relying on colour or icon shape alone. Provide a suitable text alternative when an image carries information.
Follow keyboard focus from entry to completion. Can a member reach search, open a result, enter a discussion and leave an editor or pop-up without becoming trapped? Is focus visible, and is its movement understandable? Record the step that fails, along with the member role and relevant browser and settings.
Check contribution and recovery
Inspect joining, posting and reporting forms. Fields need clear labels and necessary instructions. State which fields are required.
When submission fails, identify the affected field and explain the error in text. Confirm success so members know whether a post or report was received.
Give members enough time to compose and correct a contribution where the task permits it. If a session or draft expires, check the actual limit, whether it can be extended and what happens to entered text. Do not promise draft recovery unless the chosen setup demonstrates it.
Treat reporting as an essential task. Someone blocked by the ordinary editor still needs another stated way to tell the team about a barrier. Keep private details out of a public troubleshooting thread.
Evaluate and record the limits
Use the Web Content Accessibility Guidelines 2.2 as a technical reference, alongside realistic task evaluation with people who use relevant assistive technologies. Agree on the task and account permissions, observe barriers and record the setup. Include more than one pattern of use where possible. A short session can reveal a barrier; it cannot establish that every screen, device or member need is covered.
For each issue, record the task, setup, observed barrier, owner, proposed fix and recheck. Prioritise a blocked essential task. Recheck after platform updates, theme changes or new interactive features. Until a barrier is resolved, give members an alternative route that the team has checked in its own setup.
