Ein Überblick über den Testprozess zur Barrierefreiheit von Deque…

Glenda Sims

By Glenda Sims

7. März 2013

At Deque, one of the services we offer is a “full-package” evaluation of individual web pages for accessibility. This kind of evaluation can be broken down into testing with accessibility testing tools like FireEyes and WorldSpace, testing with a screen reader like JAWS, keyboard-only testing, and, finally, writing up the evaluation.

I recently polled my team members to see how much time they spend on each of these parts of the process. The percentage of time spent on keyboard-only testing is about 10% of the time estimated for the full-package testing of the web page.

While the estimate for keyboard-only was consistent across all of the Deque Accessibility Experts I polled, the estimate for time spent conducting screen reader testing differs. Since web accessibility testing with a screen reader and other accessibility testing tools is a high level skill requiring detective work and analysis, we do not have a cookie cutter recipe for how our experts use the tools.  Instead, we ask our experts to conduct the testing within the estimated time frame, applying the appropriate standard (WCAG 2.0 AA in this case), and we have them use their professional judgement to use screen readers and other testing tools in an effective and efficient way.

Team Member Results

Results from Expert #1

  • 30% testing with accessibility testing tools (not a screenreader, and not keyboard alone)
  • 35% testing with a screen reader
  • 10% testing for keyboard alone
  • 25% finalizing write up

Results from Expert #2

  • 45% testing with accessibility testing tools
  • 25% testing with a screen reader
  • 10% testing for keyboard alone
  • 20% finalizing write up

Results from Expert #3

  • 40% testing with accessibility testing tools
  • 30% testing with a screen reader
  • 10% testing for keyboard alone
  • 20% finalizing write up

So on average, bearing in mind that an average page on the web takes 3 hours to full evaluate, that’s 38% spent using accessibility testing tools, 30% testing with a screen reader, 10% keyboard-only testing, and 22% on the write up.

If you’d like to learn more about the benefits of automated testing vs. manual testing, be sure to read our whitepaper on a 360? Approach to Web Accessibility Testing.

 

 

 

Glenda Sims

Glenda Sims

Glenda Sims ist Chief Information Accessibility Officer bei Deque, wo sie ihr Fachwissen und ihre Leidenschaft für das offene Web an Behörden, Bildungseinrichtungen und Unternehmen aller Größenordnungen – von Kleinunternehmen bis hin zu großen Konzernen – weitergibt. Glenda ist Beraterin und Mitbegründerin von AIR-University (Accessibility Internet Rally) und AccessU. Sie ist als Beraterin für Barrierefreiheit, Jurymitglied und Trainerin für Knowbility tätig, eine Organisation, deren Ziel es ist, die Selbstständigkeit von Menschen mit Behinderungen durch die Förderung barrierefreier IT zu unterstützen. Im Jahr 2010 war Glenda Mitautorin des Buches „InterACT with Web Standards: A holistic approach to Web Design“.

Erhalten Sie Blog-Beiträge direkt in Ihren Posteingang

Kein Geschwafel, sondern echte Erkenntnisse zum Thema Barrierefreiheit von qualifizierten Experten.

Sie erklären sich damit einverstanden, dass Deque Informationen gemäß den Bestimmungen in DequeDatenschutzerklärungbeschrieben, Informationen von Deque entgegennimmt, nutzt und weitergibt. Sie können Ihre Einwilligung jederzeit widerrufen, indem Sie uns kontaktieren.

Mehr zu diesem Thema

Testen Sie Ihre benutzerdefinierten Elemente und verlassen Sie sich auf die Ergebnisse – dank der Unterstützung von „ElementInternals“ durch Axe-core

Wilco Fiers 400 × 400 1 300 × 300
27. August 2026 Von Wilco Fiers

Wenn Sie ein großes Unternehmen sind, das aufgrund von Interoperabilitätsproblemen mit Barrierefreiheitsproblemen zu kämpfen hat, ist die Umstellung auf ElementInternals ein kluger Schachzug. Sie können standardisieren und sicher testen. Und da „ Axe-core “ nun ElementInternals unterstützt, können Sie diese Komponenten testen und sich auf die Ergebnisse verlassen.

Artikel lesen
Ein Testablauf, der eine einzelne benutzerdefinierte Schaltfläche veranschaulicht, die von „ Axe-core “ für die Frameworks React, Angular oder Vue erfasst wird

Deque und Microsoft: Zwei Jahrzehnte, in denen wir die Zukunft der Barrierefreiheit geprägt haben

beschnittenes Bild „preety kumar400x400 300x300 1 1.jpg“
25. August 2026 Von Preety Kumar

Was vor fast zwei Jahrzehnten als Austausch zwischen zwei Menschen begann, die sich leidenschaftlich für die Verbesserung der Barrierefreiheit in den digitalen Angeboten von Microsoft einsetzten, hat sich zu einer dauerhaften Partnerschaft entwickelt, die auf gemeinsamem Lernen, gegenseitigem Respekt und der gemeinsamen Überzeugung basiert, dass Barrierefreiheit in jeder Phase der Softwareentwicklung berücksichtigt werden sollte.

Artikel lesen
Preety Kumar und Jenny Lay-Flurrie führen ein Interview, im Hintergrund ist die Skyline von Seattle zu sehen.