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 even though the WCAG criteria focus primarily on functional requirements that are evident to users such as those using aid devices through the technical implementation of the service, a large portion of WCAG and accessibility shortcomings are rooted in the pre-coding specification process or even a lack thereof.

Insufficient specification

Poor specification work will lead to situations in which the developers and designers have to – sometimes very spontaneously and with little background information – carry out quite crucial specification work and thus service design in order to facilitate the desired functions within the desired schedule. The project leaders assume that the developer knows how each function should be implemented as long as the general framework is known – it is, after all, the developer’s job. However, the developer 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 of the service specification materials.

What follows is that coming up with user interface solutions will “trickle down” all the way to the developer, as they are the last stop at which many questions have to be answered in order for the functions to be implemented. Examples of such solutions include the technical browsing order of contents, the use of technical modal structures and how the user’s browser focusing should be approached in different functions related to online forms. The developer may also have to decide how the different logical content areas of the page should be presented from the perspective of aid devices due to no one having even known to think about the matter before coding – and all of a sudden, the landmarks just have to be written into the code in order to have a test version released.


Decisions such as the aforementioned have a major impact on the usability of the service, however, and they should be made in connection with specification and thus the next design job in order to ensure that the persons the most familiar with each requirement are involved in the decision-making. This problem appears to apply to agile and more conventional development processes alike.

The division of labour in the specification process can also be more broadly unclear. For example, if a service designer has documented a user interface structure related to a certain function (logical content order, element types, areas), can a visual designer deviate from the instructions, and if so, to what extent and on whose mandate? If the two designers are different subcontractors, which one has the authority? If the visual designer has the right to take liberties in terms of service design, it may cause significant risks to the fulfilment of the accessibility requirements and the usability of the service, as the designer is not necessarily informed on the basics according to which service design decisions have been made in each situation and due to which even the smallest deviation can be critical.

When such a visual design or prototype is submitted to the developer, they may in turn have to wrestle with conflicting documentation or have to again come up with their own (and thus the third different person’s) interpretation of the requirements for the functions.

It is obvious that the fulfilment of 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 island or a project phase that is carried out separately from the other work. Instead, the accessibility requirements form an integral part of the normal set of requirements for the service that includes both functional (what individual actions can be performed in the service) and non-functional (e.g. performance, responsiveness, browser version support, etc.) requirements.

  1. 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.

  1. 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, so that any design-related issues detected in the implementation phase are always circulated through updated design and no significant independent variations are created in the implementation phase in relation to the service design instructions without permission from the designer or a steering group consulting with the designer.
    • Although the service designer and/or the developer and/or the graphical designer can be the same person, any significant changes made during development should always be documented in order to facilitate efficient maintenance and further development of the project – which may be carried out by other professionals – and avoid ignoring any key accessibility-related solutions that were “obvious” in 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 extremely recommendable that an open communication channel, such as Slack, be established between the professionals to enable them to talk outside meetings and without unnecessary red tape about things that affect the decisions made in the development of the service. For example, the graphical designer and the service designer should be able to ask the coders whether there are any implementation-related issues or features in the proposed plan that affect whether the plan is worth taking to the prototype or user testing phase; or whether solution A is more cost-effective than solution B, etc. In turn, if the developer deems solution C to be the smartest, they should be able to check with the graphical designer on short notice whether the related CSS change is OK, etc.
    • This working method may require that it be taken into consideration early on in connection with the tendering and budgeting processes, in terms of time use and calendar reservations alike. All parties should be at least somehow available throughout the entire project and not just in individual lifecycle phases in order to make collaboration possible.
    • On the other hand, experience has shown that the more closely the different professionals involved in the project are able to collaborate, the more efficient the development is, so the cost effect can be very positive in the grand scheme of things.
    • The cost effect is particularly significant whenever accessibility breaches can be prevented early on in the development phase and are not left in to be remedied in the auditing phase.
  • Read the accessibility auditing instructions in Module 6. Prepare for an audit. Specify who will be responsible for remedying any accessibility shortcomings and at whose cost.
  1. 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