Accessibility Adaptation

Snabblänkar
Vilka omfattas av Tillgänglighetsanpassning?
Vad är syftet med Tillgänglighetsanpassning och hur kan de se ut rent praktiskt?
Vad säger lagen om Tillgänglighetsanpassning av programvara som Stratsys?
        - WCAG
        - Digg och Dos
        - Lag (2018:1937)
Här kan du läsa vår Tillgänglighetsredogörelse för Stratsys
Inom vilka områden arbetar Stratsys aktivt med förbättringar inom Tillgänglighetsanpassning?
        - De 3 oftast förekommande Skärmuppläsarverktygen
Övriga delar av Tillgänglighetsanpassningen

Who Is Covered by Accessibility Adaptation?

The following actors that fall under the scope of accessibility requirements:

WCAG - Developed by W3C – World Wide Web Consortium, WCAG defines international accessibility standards. Organizations are expected to comply with levels A, AA, or AAA, where AAA is the most extensive.
Public authorities are legally required to meet at least level AA, where applicable.

DOS – A public actor refers to state and municipal authorities, decision-making assemblies in municipalities and regions, publicly governed bodies, as well as associations of these actors. The term also includes certain private entities, such as schools and healthcare providers.

Swedish Law (2018:1937)- 4§ - A public actor is defined as a state or municipal authority or a decision-making assembly in a municipality or a region.

 

The individuals within the above organizations who are covered include:

• People with disabilities, defined as individuals who have a reduced functional capacity—this may be related to vision, mobility, hearing, cognition, and/or neurological functioning.
• A functional impairment refers to the limitations a person may experience in interaction with their enviroment.

- delorean.se

What Is the Purpose of Accessibility Adaptation and What Does It Look Like in Practice?

Overall Purpose:
To adapt our digital environment for everyone in society in the same way we adapt our physical environment.

In Practice, This Means That:
Public actors as defined in WCAG, DOS, and Swedish Law (2018:1937) are responsible for making all necessary adjustments in accordance with WCAG 2.1, level AA, to the extent possible. They must also ensure that third-party software meets these requirements.

Information about the adaptations made must frequently be documented in an Accessibility Statement, in accordance with Swedish Law (2018:1937) -13§ -.

In addition, it is required to ensure that users are given the opportunity to report deficiencies and request information in a format that is accessible to them.

 

Examples of Accessibility Adaptations:

• Design the website/app with clear contrast between background and text, and allow users to enlarge text and increase line spacing

• Implement responsive design to ensure usability across devices

• Ensure all code follows standards and that roles/functions of components are properly defined

• Allow users to navigate using the keyboard

• Provide the ability to disable sound, video, and animations

• Use text descriptions for all non-text content (e.g., video and graphics — decorative images are exempt)

• Write descriptive headings and labels

• Use clear, meaningful link texts (e.g., avoid vague links like “Click here”)

 

What Does the Law Say About Accessibility Adaptation of Software Like Stratsys?

Stratsys as a software solution is generally considered exempt from the requirements stated in DOS and Swedish Law (2018:1937), as it falls under a common exception listed in both regulations:

DOS and Law (2018:1937):

"...a digital service from a third party that has neither been funded nor developed by the concerned public actor, nor is under its control."

 

Accessibility requirements may still be relevant during a procurement process and can be specified according to the definition "as far as possible" under the Swedish Public Procurement Act (LAG 2016:1145). However, what this definition actually entails is open to interpretation according to Proposition 2017/18:299, pages 28 and onward, for LOU.

The legislator has deliberately avoided a fixed definition, as it is not feasible; it depends on the technical solution used and the extent to which it can be made accessible at the time the digital service is published. 

 

In other words, LOU places stricter demands than other laws regarding accessibility adaptation, which is also supported by DIGG’s interpretation of LOU [LINK].

Under Frequently Asked Questions, we find the following:

What applies to content produced by, for example, a consultant or another public entity that we publish on our website or app?

What is exempt under §9 can be summarized as content over which the organization does not have control due to third-party involvement—such as user-generated content like comments and comment sections for social media or articles—and therefore lacks the ability to modify it. In such cases, §12 may be invoked on the grounds that adaptation would be unreasonably burdensome.

 

Further down, however, we find a statement that clearly applies to Stratsys:

...Functions that consist of third-party solutions and are integrated on the website should be considered the responsibility of the public entity, for example through procurement requirements.

In addition to the DOS Act and Act (LAG 2018:1937), organizations are also subject to the Discrimination Act (2008:567), §4 on Discrimination, point 3 on lack of accessibility:

...that a person with a disability is disadvantaged because such accessibility measures have not been taken to place that person in a comparable situation with individuals without such a disability, where such measures are reasonable based on accessibility requirements in law and other regulation, taking into account

– the financial and practical conditions,
– the duration and scope of the relationship or contact between the service provider and the individual, and
– other relevant circumstances.

In short:
The degree of accessibility adaptation is regulated in the agreement between the customer and Stratsys and is based on the requirements imposed on the customer’s organization by the legislation cited above, as well as Stratsys’ ability to technically meet those requirements at the given time.

 

Stratsys, as a company, continuously works to improve accessibility in accordance with the international standard WCAG 2.1, aiming for a minimum compliance level of AA. Accessibility adaptation aligns closely with our vision for a better working life:

...to make it as easy, secure, and above all, as smooth as possible to work together.

In addition, our strong customer focus means we strive—wherever possible—to support you with the information needed to create an Accessibility Statement in accordance with the Act (2018:1937), as well as with relevant guidance for procurement processes.

For more information, see the section titled Here you can read and download our Accessibility Statement.

WCAG

These are guidelines for accessibility adaptation developed by the W3C – World Wide Web Consortium. The guidelines are assigned based on the type of organization, according to the standards A, AA, and AAA. Public authorities are required to comply with at least level AA wherever possible.

DIGG and DOS

DIGG, or the Swedish Agency for Digital Government, is responsible for enforcing the Act on Accessibility to Digital Public Services in Sweden. The law pertains to the requirement that public entities' websites and mobile applications must be accessible.

Act: DOS	Sections: NA	Link: DIGG [LINK]
Name: Act on Accessibility to Digital Public Services (Digital Offentlig Service)
Applies to: Public actors include state and municipal authorities, decision-making assemblies in municipalities and regions, publicly governed bodies, and associations of these entities. The term actor also includes certain private entities, such as schools and healthcare providers. For more detailed information, see – Link. [LINK]
Requirements in the Act: The act contains provisions stating that services and information provided by a public entity through a website or mobile application must be accessible. Such digital services must meet the following criteria: Perceivable Operable Understandable Robust By following a specific European standard (EN 301 549 V2.1.2), which in turn is based on WCAG 2.1, websites and mobile applications can meet these requirements. For more detailed information, see – Link. [LINK]
Exemptions: Link [LINK] Certain digital public services are exempt from the requirements of the act. This applies to digital public services that: originate from a third party and have neither been financed nor developed by the relevant public entity, nor are under its control.
Key Dates: Link [LINK] The requirements take effect at different times depending on whether it is an existing or a new website, or if it concerns a mobile application. Existing websites refer to those published before 23 September 2018. Websites published after that date are considered new. The following dates apply for compliance: New websites: 23 September 2019 Existing websites: 23 September 2020 Mobile applications: 23 June 2021

Act (2018:1937) on Accessibility to Digital Public Services

The act sets out provisions regarding accessibility requirements for digital services provided by a public entity.

Act: (2018:1937)	Sections: 9§ och 11§	Link: Lag (2018:1937) [LINK]
Name: Act (2018:1937) on Accessibility to Digital Public Services
Applies to: §4 – A public entity refers to a state or municipal authority or a decision-making assembly in a municipality or region. For more detailed information, see – Link .
Requirements in the Act: §11 – Digital services provided by a public entity through a technical solution under third-party control shall, as far as possible, comply with the accessibility requirements set out in regulations issued under this act. §13 – A public entity shall, for digital services referred to in §10, provide an accessibility statement. The statement must include a function that allows an individual to notify the relevant entity that its digital service does not meet the accessibility requirements, or to make a request as referred to in §15. If a public entity considers it unreasonably burdensome to fulfill the requirements under §10, this assessment must be included in the accessibility statement. For more detailed information, see – Link.
Exemptions: §9 –  point 3: Digital services from third parties that have neither been financed nor developed by the relevant public entity, and are not under its control.
Key Dates: Link  This act entered into force on 1 January 2019. The provision in §11 applies only to digital services provided for the first time after 22 September 2020.

 

Here You Can Read Our Accessibility Statement for Stratsys

Stratsys Accessibility Statement – Link

 

Stratsys is actively working on accessibility improvements within the following areas:

Views

Reports

PDF Exports

The three most commonly used screen reader tools are:

We actively work with both JAWS and NVDA in the development of Stratsys to ensure a high level of accessibility for users with visual impairments or blindness. We also test ongoing development with Stratsys users who work daily in the tool using screen readers, in order to gather feedback and improve and simplify their experience in Stratsys.

Other Aspects of Accessibility Adaptation

It’s easy for much of the focus to be placed on screen reader tools and that specific category of accessibility. Therefore, here is a brief but complementary summary of the areas included in accessibility adaptation and what to consider:

 

Category:	Avoid:
Autism and Aspergers	Complexity and Intense Sensory Input
Work with simple colors, plain text structured in bullet points, and use self-explanatory buttons. In terms of layout, the interface must be consistent throughout.

 

Category:	Avoid:
Dyslexia	Large and Complex Text Blocks
Use plenty of images and present text blocks in a consistent layout. If possible, offer audio recordings or text-to-speech functionality. Write in a concise and simple manner, and allow users to adjust the contrast between text and background when possible.

 

- Github