Use cases

The easiest way to start is to go to My pages and create a new review there by clicking Start a new audit. Choose what you are reviewing and whether you will use all the requirements in the checklist or only EN 301 549 or WCAG.

Once you have set up a protocol, you can initiate an automatic review to give you some support in assessing the requirements in the checklist. You do that directly from the protocol you created. You can use the automatic tool regardless of whether it is an open interface or an interface behind a login, or an e-service.

The protocol can also be shared, and you can easily invite accessibility experts to help you with the more challenging assessments.

Go to My pages and select Create a list with requirements. You choose which role(s) you want to create checklists for, whether it should span mobile apps or web interfaces, and whether it should include only requirements mapped to the guidelines or all requirements in Aceit's checklist.

You can export the filtered list of requirements that appears after you have chosen to create the list of requirements to Excel. From there, you can then choose what information to include, make organisation-specific changes and additions, and finally either distribute as Excel or transfer to Word or make a PDF.

In addition to saving the information as checklists and manuals, you can also use the results of audits to disseminate information within and outside the organisation. You can choose to share the completed protocol (audit). When sharing a protocol, you get both a read-only link and a link that gives the user the option to make changes to the protocol. Share the appropriate link with those concerned within the organisation and/or external suppliers.

A good way to spread knowledge in the organisation is also to set up empty protocols for your interfaces, and then share an editable link to the protocol with system owners, project owners, or other important stakeholders. Then let them make a first attempt themselves to audit the interface with the instructions in Aceit.

This gives them a good insight into what it means to create accessible interfaces, something that is essential for their ability to understand that all roles in the project/organisation have a responsibility, and to understand what resources are required for accessibility testing in projects and procurement. Let them do most of the work, but at the same time offer them support and help them with the more challenging parts of the testing. It's not about letting them do everything or getting a perfect protocol. The aim is to show the scope and give them an insight into what it is all about.

Start by making a list of requirements. Go to My pages and select Create a list of requirements. Define whether it is a web interface or an app that you are going to procure and whether you only want EN 301 549, or all requirements.

Once you have created the list, you can download it as an Excel file. The Excel file has two tabs. In the second tab you can enter assessments of whether an interface meets the requirement or not, in the same way as in a protocol. This is a document that you can use during procurement and ask the suppliers to self-declare the product's accessibility status, comment on any accessibility violations, and report when the problems can be corrected.

If you procure consultants, you can use the requirements lists to ask the suppliers to self-declare the accessibility status of one or several reference interfaces. Note, the most important thing is not that the reference interfaces are perfect, but that the supplier is aware of the shortcomings. You want to know that they understand accessibility.

Use the same list of requirements later to verify that the suppliers have been truthful, and to follow up on deliveries in the project. It is important to use the same clear requirements throughout the process so that everyone involved can easily see what is expected of them.