Good service specification practices

Challenges observed in practical projects

The accessibility requirements can only be met in service development projects in a cost-effective manner if accessibility is taken into consideration throughout the entire service development process. The reason for this is that, although the WCAG criteria primarily address functional requirements visible to users, such as those using assistive devices, many accessibility issues actually originate from the pre-coding specification process or the absence of such specifications.

Insufficient specification

Poor specification work leads to situations where developers and designers must quickly make crucial decisions regarding specification and service design without the sufficient background information. Project leaders may assume that developers know how each function should be implemented as long as the general framework is known. However, developers should not be tasked with service design if it is not expressly part of their job description and if they do not have adequate information about all the service specification materials.

As a result, developers end up having to make important decisions about the user interface because they are the last ones who can address these issues before implementing the functions. For example, they have to decide the technical order in which content should be presented, how to use modal structures, and how the browser should focus on different parts of online forms. Developers may also need to determine how different content areas should be accessible to assistive devices because no one considered this before coding started. Suddenly, they have to add these accessibility features into the code just to get a test version ready.

Impacts

Decisions such as the aforementioned have a major impact on the usability of the service. Such decisions should be made in connection with specification and thus the next design task. This way the persons most familiar with each requirement are involved in the decision-making. This applies to both agile and more conventional development processes.

The division of labor in the specification process can often be unclear. For instance, if a service designer has created a user interface plan detailing the logical order of content, element types, and areas, can a visual designer make changes to these instructions? If so, to what extent and with whose approval? This issue becomes more complicated if the two designers are different subcontractors. Who has the final authority? If the visual designer is allowed to make changes, it could jeopardize the accessibility and usability of the service. The visual designer may not understand the rationale behind the service design decisions, and even small deviations could have significant impacts.

When such a visual design or prototype is submitted to the developer, they may need to deal with conflicting documentation or resolve these conflicts themselves, leading to yet another interpretation of the functional requirements.

It is clear that meeting the accessibility requirements cannot be guaranteed with an unclear division of labour and specification. Unfortunately, these problems are common in practical development projects.

Good practices

1. Take the accessibility requirements into account right from the start.

Accessibility is not an isolated project phase that is carried out separately. Instead, the accessibility requirements form an integral part of the normal set of requirements for the service. This includes both functional (what individual actions can be performed in the service) and non-functional (e.g. performance, responsiveness, browser version support, etc.) requirements.

2. Utilise user stories and support specification with use cases.

Use cases and user stories form an effective tool in the specification of digital services. They are discussed in greater detail in Module 2. They are an excellent help, especially if it feels difficult to grasp what different accessibility requirements pertain to each function of the service. It is actually a common mistake to always specify the requirements through the entire extensive WCAG criteria with the idea of making a checklist of everything that will supposedly be needed. That method usually fails. A better strategy is to think about the requirements through the functions and function paths carried out by users in the service. That way, finding the criteria will be much easier.

3. Define roles and responsibilities.

Even before use cases are created or iterated, it should be made sure that any confusion over responsibilities, such as the issues described at the beginning, will not occur when the specification, design and prototyping phases start (often side by side in agile development). Think about and make notes of the following:

  • Specify how service design, visual design and technical implementation are divided between the different operators or resources.
    • Give service design the highest authority that the graphical and technical implementation must comply with. Any design-related issues detected in the implementation phase are always circulated through the updated design. No significant changes should be made from the service design instructions during implementation without approval from the designer or a steering group in consultation with the designer.
    • Even if the service designer, developer, and graphical designer are the same person or different individuals, any significant changes made during development must always be documented. This ensures efficient maintenance and future development, which may involve other professionals. It also helps to avoid overlooking any important accessibility solutions that may seem “obvious” during the implementation phase.
  • Aim to bring the service designers, graphical designers and developers to the same table when the service is being specified.
    • It is highly recommended to establish an open communication channel, such as Slack, between professionals involved in the project. This allows them to discuss matters outside formal meetings and without unnecessary bureaucracy, especially regarding decisions affecting the service development. For instance, the graphical designer and the service designer should be able to ask the developers about any implementation-related issues or features in the proposed plan before moving to the prototype or user testing phase. They might also discuss whether solution A is more cost-effective than solution B, and so on. Likewise, if the developer believes solution C is the best choice, they should be able to quickly check with the graphical designer if the related CSS change is acceptable, and vice versa.
    • This working method may require early consideration during the tendering and budgeting processes regarding time allocation and scheduling. All parties involved should be at least somewhat available throughout the entire project, not just in specific phases, to enable effective collaboration. This means ensuring availability is accounted for in project timelines and resource planning from the outset.
    • On the other hand, experience has shown that the closer collaboration between various professionals involved in the project, the more efficient the development becomes, leading to potentially positive cost effects overall.
    • This cost-effectiveness is especially notable when accessibility issues can be addressed early in the development phase, rather than waiting to fix them during the auditing phase.
  • Read the accessibility auditing instructions in Module 6. Prepare for an audit. Specify who will be responsible for remedying any accessibility issues and at whose cost.

4. Prepare for accessibility maintenance after the service has been launched.

  • Appoint an owner for the accessibility of the service. They will be responsible for ensuring that the accessibility requirements of the service are not forgotten or neglected when content is created for the service and the service is developed.
    • Experience has shown that the accessibility of services does not automatically stay at the level of the publishing phase. For example, new contents such as new HTML pages or PDF documents can inadvertently breach the service’s own specifications. On the other hand, further development should always be as meticulous as the original implementation of the service, as it is also subject to the same legal requirements. Finally, keep in mind that the accessibility statement of the service must be updated on a regular basis.
    • The owner of accessibility must ensure that content production for the service follows the instructions set for it and that any further development of the service will not bypass the requirements of the Act on the Provision of Digital Services.
    • If one automatic tool is used for monitoring the accessibility of the service, the owner should have the appropriate user rights and training for it.
    • The owner also primarily receives and processes the accessibility feedback provided through the accessibility statement.
  • Assess whether an accessibility monitoring tool is needed to maintain the service and whether one can easily be acquired, e.g. through a framework agreement.
    • If you are able to utilise automatic accessibility monitoring, specify who will use the tool and what resources and obligations that entails.
    • For example, if the monitoring tool reports any specification breaches that have occurred in content production (e.g. pages without technical heading specifications have been added to the service or a link to an external service has not been marked correctly on a new page), specify in advance what action the user of the tool, such as the owner of the accessibility of the service, can take in the situation.

Original version: Tero Pesonen / Siteimprove
Created: 3 April 2021