https://wiki.diglib.org/api.php?action=feedcontributions&user=Dkrahmer&feedformat=atomDLF Wiki - User contributions [en]2024-03-28T10:01:18ZUser contributionsMediaWiki 1.41.0https://wiki.diglib.org/index.php?title=IT_and_Development&diff=16711IT and Development2024-03-08T16:42:45Z<p>Dkrahmer: /* Accessibility Audits */</p>
<hr />
<div>The IT and Development subgroup will focus on specific software, hardware, and development practices associated with information organizations. Once a list of technologies associated with specific areas is compiled, they will begin addressing the accessibility concerns of specific entries. We adhere to the same mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group]. <br />
<br />
==Monthly Meetings==<br />
<br />
For 2024, the DLF DAWG-IT subgroup is focusing on updating our documentation and assessing the accessibility of other GLAM technologies. We're primarily focusing on digital publishing platforms.<br />
<br />
Meetings will be held on the final Monday of the month, at 1:15pm Eastern/6:15pm GMT. ([https://www.thetimezoneconverter.com/ Timezone converter]) Check the [https://docs.google.com/document/d/1VNUIGFd7EOwcVpR73qQzhi9K5ZZCTrFS4hDLiu6AN8U/edit 2024 running agenda] for more information, including links to register for the meetings.<br />
<br />
== Completed Projects ==<br />
* [[Accessible Documentation]]<br />
* [[Accessibility Auditing Resources]]<br />
* [[Accessibility Auditing Shortlist]]<br />
* [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit?usp=sharing Accessibility Auditing Template] Google Doc. Make a copy to start your own evaluation.<br />
<br />
== Accessibility Audits ==<br />
In 2021, the DAWG-IT subgroup focused on accessibility testing of the software typically used for DAWG meetings and events. For 2022, we focused on broader GLAM software. In 2023, we updated our Auditing Shortlist and continue to test GLAM applications. In 2024, we focused on digital publishing platforms. These are our completed audits:<br />
<br />
* [[Zoom Accessibility]]<br />
* [[Doodle.com Accessibility]]<br />
* [[Google Forms Accessibility]]<br />
* [[Otter.ai Accessibility]]<br />
* [[Google Docs Accessibility]]<br />
* [[Google Slides Accessibility]]<br />
* [[Zotero Accessibility]]<br />
* [[Online Conference Platforms Accessibility]]<br />
* [[ArchivesSpace Accessibility]]<br />
* [[AirTable Accessibility]]<br />
* [[PressBooks Accessibility]]<br />
* [[Scalar Accessibility]]<br />
<br />
== Group Organizers ==<br />
* Debbie Krahmer dkrahmer AT cornell.edu<br />
<br />
== Members ==<br />
* Ima Odouk<br />
* Elliot Stevens<br />
* Wendy Robertson<br />
* Kristen Heldmann<br />
* Gabe Galson<br />
* Hannah Sistrunk<br />
* Rita Johnston<br />
* Penniphurr Stevenson<br />
* Eudora Struble<br />
* Deseree Stukes<br />
* Jonathan Milam<br />
<br />
== Future Technologies to Research ==<br />
Everyone is welcome to participate, regardless of your own personal level of skill with accessibility auditing. We've compiled an [[Accessibility Auditing Shortlist]] that anyone can use to contribute to the knowledge base. The ultimate goal for all of these audits is to make the information freely available to anyone. Google docs is currently used for the initial working document before moving information to the wiki. Contact the Organizers for information on how to join the community and get wiki editing access.<br />
<br />
* [https://docs.google.com/document/d/1gAS04mUZSM7g1VBcF5kfry0uuHqvMQc21nXso20h5Pg/edit?usp=sharing Google Sheets]<br />
* [https://docs.google.com/document/d/1vGJey7_KQdM0lLYAdt9W8DkiuWaJXKF-BuvDulsUMbA/edit?usp=sharing Slack]<br />
* OJS, open journal systems<br />
* Institutional Repositories (bepress, DSpace, etc.)<br />
* DAMs (Contentdm, Islandora, etc.)<br />
* Library Systems<br />
* Virtual Tours<br />
* Digital Scholarship (Research data, tools, visualizations)<br />
* Databases and Vendors<br />
* Virtual Reality (3D technologies, including Makerspace equipment)<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Scalar_Accessibility&diff=16710Scalar Accessibility2024-03-08T16:41:50Z<p>Dkrahmer: /* Known Accessibility Issues */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of Scalar. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
Created by the Alliance for Networking Visual Culture, Scalar is a digital publishing platform with a heavy visual media focus. In general, we found that Scalar was '''not accessible'''. We tested several ebooks created with Scalar as they appeared on their Showcase page, as well as the authorship platform. We encountered several major barriers for screen reader users as well as those who rely on keyboard navigation.<br />
<br />
== General Information ==<br />
<br />
We were unable to find any VPAT or page on accessibility support on Scalar's website. We used the contact us to request a VPAT and ask questions, but never received a response after 5 months. <br />
<br />
* [https://teachdh.sdsu.edu/tools/scalar/ Overview of Scalar] geared toward online instruction courses<br />
* A Pressbook on [https://pressbooks.library.yorku.ca/scalar/ Digital Publishing with Scalar] from York University (there is no mention of accessibility in the Pressbook)<br />
* [https://scalar.usc.edu/works/guide2/index Scalar User's Guide] (doesn't include any info about accessibility)<br />
<br />
== Known Accessibility Issues ==<br />
<br />
=== Keyboard Control ===<br />
<br />
We were unable to find any information on keyboard shortcuts for the Scalar platform. Some sites created with Scalar were somewhat navigable by keyboard, while others were not. The visualizations we were able to access could not be navigated and used by the keyboard only. On the creator end, the tabs were keyboard navigable, but not the sub tabs nor the main content areas.<br />
<br />
=== Screen Reader Access ===<br />
<br />
While most of the tested sites were at least minimally navigable with a screen reader, there were missing alt text and incorrect headings that got in the way. On some pages, the navigation menu was not usable with a screen reader. On the backend, there was broken ARIA and navigation issues that were the same as with keyboard control. <br />
<br />
=== Other Accessibility Issues ===<br />
<br />
After 200% zoom, the menus become inaccessible. Several low color contrast errors were reported on several pages, as well on the creator side. The link text also came up as low contrast. <br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Scalar_Accessibility&diff=16709Scalar Accessibility2024-03-08T16:31:56Z<p>Dkrahmer: /* Keyboard Control = */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of Scalar. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
Created by the Alliance for Networking Visual Culture, Scalar is a digital publishing platform with a heavy visual media focus. In general, we found that Scalar was '''not accessible'''. We tested several ebooks created with Scalar as they appeared on their Showcase page, as well as the authorship platform. We encountered several major barriers for screen reader users as well as those who rely on keyboard navigation.<br />
<br />
== General Information ==<br />
<br />
We were unable to find any VPAT or page on accessibility support on Scalar's website. We used the contact us to request a VPAT and ask questions, but never received a response after 5 months. <br />
<br />
* [https://teachdh.sdsu.edu/tools/scalar/ Overview of Scalar] geared toward online instruction courses<br />
* A Pressbook on [https://pressbooks.library.yorku.ca/scalar/ Digital Publishing with Scalar] from York University (there is no mention of accessibility in the Pressbook)<br />
* [https://scalar.usc.edu/works/guide2/index Scalar User's Guide] (doesn't include any info about accessibility)<br />
<br />
== Known Accessibility Issues ==<br />
<br />
=== Keyboard Control ===<br />
<br />
We were unable to find any information on keyboard shortcuts for the Scalar platform. Some sites created with Scalar were somewhat navigable by keyboard, while others were not. The visualizations we were able to access could not be navigated and used by the keyboard only. On the creator end, the tabs were keyboard navigable, but not the sub tabs nor the main content areas.<br />
<br />
=== Screen Reader Access ===<br />
<br />
While most of the tested sites were at least minimally navigable with a screen reader, there were missing alt text and incorrect headings that got in the way. On some pages, the navigation menu was not usable with a screen reader. On the backend, there was broken ARIA and navigation issues that were the same as with keyboard control. <br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Scalar_Accessibility&diff=16708Scalar Accessibility2024-03-08T16:31:43Z<p>Dkrahmer: /* General Information */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of Scalar. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
Created by the Alliance for Networking Visual Culture, Scalar is a digital publishing platform with a heavy visual media focus. In general, we found that Scalar was '''not accessible'''. We tested several ebooks created with Scalar as they appeared on their Showcase page, as well as the authorship platform. We encountered several major barriers for screen reader users as well as those who rely on keyboard navigation.<br />
<br />
== General Information ==<br />
<br />
We were unable to find any VPAT or page on accessibility support on Scalar's website. We used the contact us to request a VPAT and ask questions, but never received a response after 5 months. <br />
<br />
* [https://teachdh.sdsu.edu/tools/scalar/ Overview of Scalar] geared toward online instruction courses<br />
* A Pressbook on [https://pressbooks.library.yorku.ca/scalar/ Digital Publishing with Scalar] from York University (there is no mention of accessibility in the Pressbook)<br />
* [https://scalar.usc.edu/works/guide2/index Scalar User's Guide] (doesn't include any info about accessibility)<br />
<br />
== Known Accessibility Issues ==<br />
<br />
=== Keyboard Control ====<br />
<br />
We were unable to find any information on keyboard shortcuts for the Scalar platform. Some sites created with Scalar were somewhat navigable by keyboard, while others were not. The visualizations we were able to access could not be navigated and used by the keyboard only. On the creator end, the tabs were keyboard navigable, but not the sub tabs nor the main content areas. <br />
<br />
=== Screen Reader Access ===<br />
<br />
While most of the tested sites were at least minimally navigable with a screen reader, there were missing alt text and incorrect headings that got in the way. On some pages, the navigation menu was not usable with a screen reader. On the backend, there was broken ARIA and navigation issues that were the same as with keyboard control. <br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Scalar_Accessibility&diff=16707Scalar Accessibility2024-03-08T16:17:45Z<p>Dkrahmer: /* Known Accessibility Issues */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of Scalar. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
Created by the Alliance for Networking Visual Culture, Scalar is a digital publishing platform with a heavy visual media focus. In general, we found that Scalar was '''not accessible'''. We tested several ebooks created with Scalar as they appeared on their Showcase page, as well as the authorship platform. We encountered several major barriers for screen reader users as well as those who rely on keyboard navigation.<br />
<br />
== General Information ==<br />
<br />
* [https://teachdh.sdsu.edu/tools/scalar/ Overview of Scalar] geared toward online instruction courses<br />
* A Pressbook on [https://pressbooks.library.yorku.ca/scalar/ Digital Publishing with Scalar] from York University (there is no mention of accessibility in the Pressbook)<br />
* [https://scalar.usc.edu/works/guide2/index Scalar User's Guide]<br />
<br />
== Known Accessibility Issues ==<br />
<br />
=== Keyboard Control ====<br />
<br />
We were unable to find any information on keyboard shortcuts for the Scalar platform. Some sites created with Scalar were somewhat navigable by keyboard, while others were not. The visualizations we were able to access could not be navigated and used by the keyboard only. On the creator end, the tabs were keyboard navigable, but not the sub tabs nor the main content areas. <br />
<br />
=== Screen Reader Access ===<br />
<br />
While most of the tested sites were at least minimally navigable with a screen reader, there were missing alt text and incorrect headings that got in the way. On some pages, the navigation menu was not usable with a screen reader. On the backend, there was broken ARIA and navigation issues that were the same as with keyboard control. <br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Scalar_Accessibility&diff=16706Scalar Accessibility2024-03-08T15:38:26Z<p>Dkrahmer: /* General Information */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of Scalar. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
Created by the Alliance for Networking Visual Culture, Scalar is a digital publishing platform with a heavy visual media focus. In general, we found that Scalar was '''not accessible'''. We tested several ebooks created with Scalar as they appeared on their Showcase page, as well as the authorship platform. We encountered several major barriers for screen reader users as well as those who rely on keyboard navigation.<br />
<br />
== General Information ==<br />
<br />
* [https://teachdh.sdsu.edu/tools/scalar/ Overview of Scalar] geared toward online instruction courses<br />
* A Pressbook on [https://pressbooks.library.yorku.ca/scalar/ Digital Publishing with Scalar] from York University (there is no mention of accessibility in the Pressbook)<br />
* [https://scalar.usc.edu/works/guide2/index Scalar User's Guide]<br />
<br />
== Known Accessibility Issues ==<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Scalar_Accessibility&diff=16705Scalar Accessibility2024-03-08T15:15:15Z<p>Dkrahmer: /* Accessibility Overview */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of Scalar. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
Created by the Alliance for Networking Visual Culture, Scalar is a digital publishing platform with a heavy visual media focus. In general, we found that Scalar was '''not accessible'''. We tested several ebooks created with Scalar as they appeared on their Showcase page, as well as the authorship platform. We encountered several major barriers for screen reader users as well as those who rely on keyboard navigation.<br />
<br />
== General Information ==<br />
<br />
<br />
== Known Accessibility Issues ==<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Scalar_Accessibility&diff=16704Scalar Accessibility2024-03-08T14:50:21Z<p>Dkrahmer: </p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of Scalar. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
<br />
<br />
== General Information ==<br />
<br />
<br />
== Known Accessibility Issues ==<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Scalar_Accessibility&diff=16703Scalar Accessibility2024-03-08T14:48:49Z<p>Dkrahmer: Created page with "This page gathers the IT Subcommittee's resources and reviews of the accessibility of Scalar. This page will be updated as new information is available or further reviews are conducted. == Accessibility Overview =="</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of Scalar. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=IT_and_Development&diff=16702IT and Development2024-03-08T14:48:24Z<p>Dkrahmer: /* Accessibility Audits */</p>
<hr />
<div>The IT and Development subgroup will focus on specific software, hardware, and development practices associated with information organizations. Once a list of technologies associated with specific areas is compiled, they will begin addressing the accessibility concerns of specific entries. We adhere to the same mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group]. <br />
<br />
==Monthly Meetings==<br />
<br />
For 2024, the DLF DAWG-IT subgroup is focusing on updating our documentation and assessing the accessibility of other GLAM technologies. We're primarily focusing on digital publishing platforms.<br />
<br />
Meetings will be held on the final Monday of the month, at 1:15pm Eastern/6:15pm GMT. ([https://www.thetimezoneconverter.com/ Timezone converter]) Check the [https://docs.google.com/document/d/1VNUIGFd7EOwcVpR73qQzhi9K5ZZCTrFS4hDLiu6AN8U/edit 2024 running agenda] for more information, including links to register for the meetings.<br />
<br />
== Completed Projects ==<br />
* [[Accessible Documentation]]<br />
* [[Accessibility Auditing Resources]]<br />
* [[Accessibility Auditing Shortlist]]<br />
* [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit?usp=sharing Accessibility Auditing Template] Google Doc. Make a copy to start your own evaluation.<br />
<br />
== Accessibility Audits ==<br />
In 2021, the DAWG-IT subgroup focused on accessibility testing of the software typically used for DAWG meetings and events. For 2022, we focused on broader GLAM software. In 2023, we updated our Auditing Shortlist and continue to test GLAM applications. These are our completed audits:<br />
<br />
* [[Zoom Accessibility]]<br />
* [[Doodle.com Accessibility]]<br />
* [[Google Forms Accessibility]]<br />
* [[Otter.ai Accessibility]]<br />
* [[Google Docs Accessibility]]<br />
* [[Google Slides Accessibility]]<br />
* [[Zotero Accessibility]]<br />
* [[Online Conference Platforms Accessibility]]<br />
* [[ArchivesSpace Accessibility]]<br />
* [[AirTable Accessibility]]<br />
* [[PressBooks Accessibility]]<br />
* [[Scalar Accessibility]]<br />
<br />
== Group Organizers ==<br />
* Debbie Krahmer dkrahmer AT cornell.edu<br />
<br />
== Members ==<br />
* Ima Odouk<br />
* Elliot Stevens<br />
* Wendy Robertson<br />
* Kristen Heldmann<br />
* Gabe Galson<br />
* Hannah Sistrunk<br />
* Rita Johnston<br />
* Penniphurr Stevenson<br />
* Eudora Struble<br />
* Deseree Stukes<br />
* Jonathan Milam<br />
<br />
== Future Technologies to Research ==<br />
Everyone is welcome to participate, regardless of your own personal level of skill with accessibility auditing. We've compiled an [[Accessibility Auditing Shortlist]] that anyone can use to contribute to the knowledge base. The ultimate goal for all of these audits is to make the information freely available to anyone. Google docs is currently used for the initial working document before moving information to the wiki. Contact the Organizers for information on how to join the community and get wiki editing access.<br />
<br />
* [https://docs.google.com/document/d/1gAS04mUZSM7g1VBcF5kfry0uuHqvMQc21nXso20h5Pg/edit?usp=sharing Google Sheets]<br />
* [https://docs.google.com/document/d/1vGJey7_KQdM0lLYAdt9W8DkiuWaJXKF-BuvDulsUMbA/edit?usp=sharing Slack]<br />
* OJS, open journal systems<br />
* Institutional Repositories (bepress, DSpace, etc.)<br />
* DAMs (Contentdm, Islandora, etc.)<br />
* Library Systems<br />
* Virtual Tours<br />
* Digital Scholarship (Research data, tools, visualizations)<br />
* Databases and Vendors<br />
* Virtual Reality (3D technologies, including Makerspace equipment)<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=IT_and_Development&diff=16701IT and Development2024-03-08T14:47:13Z<p>Dkrahmer: /* Monthly Meetings */</p>
<hr />
<div>The IT and Development subgroup will focus on specific software, hardware, and development practices associated with information organizations. Once a list of technologies associated with specific areas is compiled, they will begin addressing the accessibility concerns of specific entries. We adhere to the same mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group]. <br />
<br />
==Monthly Meetings==<br />
<br />
For 2024, the DLF DAWG-IT subgroup is focusing on updating our documentation and assessing the accessibility of other GLAM technologies. We're primarily focusing on digital publishing platforms.<br />
<br />
Meetings will be held on the final Monday of the month, at 1:15pm Eastern/6:15pm GMT. ([https://www.thetimezoneconverter.com/ Timezone converter]) Check the [https://docs.google.com/document/d/1VNUIGFd7EOwcVpR73qQzhi9K5ZZCTrFS4hDLiu6AN8U/edit 2024 running agenda] for more information, including links to register for the meetings.<br />
<br />
== Completed Projects ==<br />
* [[Accessible Documentation]]<br />
* [[Accessibility Auditing Resources]]<br />
* [[Accessibility Auditing Shortlist]]<br />
* [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit?usp=sharing Accessibility Auditing Template] Google Doc. Make a copy to start your own evaluation.<br />
<br />
== Accessibility Audits ==<br />
In 2021, the DAWG-IT subgroup focused on accessibility testing of the software typically used for DAWG meetings and events. For 2022, we focused on broader GLAM software. In 2023, we updated our Auditing Shortlist and continue to test GLAM applications. These are our completed audits:<br />
<br />
* [[Zoom Accessibility]]<br />
* [[Doodle.com Accessibility]]<br />
* [[Google Forms Accessibility]]<br />
* [[Otter.ai Accessibility]]<br />
* [[Google Docs Accessibility]]<br />
* [[Google Slides Accessibility]]<br />
* [[Zotero Accessibility]]<br />
* [[Online Conference Platforms Accessibility]]<br />
* [[ArchivesSpace Accessibility]]<br />
* [[AirTable Accessibility]]<br />
* [[PressBooks Accessibility]]<br />
<br />
== Group Organizers ==<br />
* Debbie Krahmer dkrahmer AT cornell.edu<br />
<br />
== Members ==<br />
* Ima Odouk<br />
* Elliot Stevens<br />
* Wendy Robertson<br />
* Kristen Heldmann<br />
* Gabe Galson<br />
* Hannah Sistrunk<br />
* Rita Johnston<br />
* Penniphurr Stevenson<br />
* Eudora Struble<br />
* Deseree Stukes<br />
* Jonathan Milam<br />
<br />
== Future Technologies to Research ==<br />
Everyone is welcome to participate, regardless of your own personal level of skill with accessibility auditing. We've compiled an [[Accessibility Auditing Shortlist]] that anyone can use to contribute to the knowledge base. The ultimate goal for all of these audits is to make the information freely available to anyone. Google docs is currently used for the initial working document before moving information to the wiki. Contact the Organizers for information on how to join the community and get wiki editing access.<br />
<br />
* [https://docs.google.com/document/d/1gAS04mUZSM7g1VBcF5kfry0uuHqvMQc21nXso20h5Pg/edit?usp=sharing Google Sheets]<br />
* [https://docs.google.com/document/d/1vGJey7_KQdM0lLYAdt9W8DkiuWaJXKF-BuvDulsUMbA/edit?usp=sharing Slack]<br />
* OJS, open journal systems<br />
* Institutional Repositories (bepress, DSpace, etc.)<br />
* DAMs (Contentdm, Islandora, etc.)<br />
* Library Systems<br />
* Virtual Tours<br />
* Digital Scholarship (Research data, tools, visualizations)<br />
* Databases and Vendors<br />
* Virtual Reality (3D technologies, including Makerspace equipment)<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=User:Dkrahmer&diff=16637User:Dkrahmer2024-01-09T18:34:12Z<p>Dkrahmer: </p>
<hr />
<div>Debbie Krahmer is the Diversity and Inclusion Research Librarian at Cornell University. Debbie prefers that you not use any gendered pronouns when you refer to Debbie--just use "Debbie" or "D". Debbie can be reached at dkrahmer AT cornell DOT edu. Debbie is the chair of the IT subgroup of the Digital Accessibility Working Group, and a co-chair of the Committee on Equity and Inclusion.</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16625Accessibility Auditing Shortlist2023-11-22T14:40:10Z<p>Dkrahmer: /* Considerations for non-English and Multilingual items */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Considerations for non-English and Multilingual items==<br />
The [https://www.w3.org/International/questions/qa-html-language-declarations language of a website or document should be properly declared], including in PDFs and epubs. This tells a screen reader what language the document is in, and that it should switch to a different voice engine. This works [https://www.freedomscientific.com/SurfsUp/Languages.htm automatically with JAWS], but [https://nvda.groups.io/g/nvda/topic/multi_language_support/25171008 may not function correctly with NVDA] or other screen readers or [https://uxdesign.cc/the-troubled-state-of-screen-readers-in-multilingual-situations-f6a9da4ecdf3 even certain browsers]. You may need to manually switch your language engine when testing a website that is in a different language than your screen reader's default setting.<br />
<br />
A website or document can also support multiple languages. [https://accessibility.psu.edu/foreignlanguages/langtaghtml/ Penn State's page on Language tags] clearly outlines the use and function of using language tags to mark out different languages on a webpage. The links in the above paragraphs include sections of multiple language tags so you can test our your preferred screen reader and browser to determine if it will function correctly for testing.<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# If the vendor or website has an internal search mechanism (i.e. search box to search the site), test to see if it actually works. You can compare it to a similar search in Google using site searching (add site:website.com to your search string in Google, replacing the address with the top level domain of the site you want to search). <br />
## Rationale: A working internal search can save a user a lot of time and energy if it works. Optimally, you could use the internal search to find the keyboard shortcuts, vpat, or other accessibility information. If the internal search doesn't work, then it's useless to help anyone.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
# Test out basic keyboard-only access to the website.<br />
## Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes? <br />
### Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit [https://nomouse.org/ Take the #NoMouse Challenge] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics].<br />
## Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
### Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.<br />
## Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?<br />
### Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.<br />
## Does the vendor include a list of keyboard shortcuts? Record that information. <br />
## How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?<br />
# Does the website or software require the user to drag-and-drop to do something, without having an alternative?<br />
## Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
# Does the website use color alone to denote meaning? <br />
## Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
## Does being color blind in some way affect a user’s ability to fully use the site? Is there a difference in color between a visited link and a non-visited link?<br />
### Rationale: Using color alone can affect how users who are color blind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
# Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
## Is any information cut off or made incomprehensible or inaccessible?<br />
## Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All?<br />
### Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%.<br />
# Are the links on the website accessible?<br />
## Are the links a different color from the regular text? Are they underlined?<br />
### Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. [https://webaim.org/resources/contrastchecker/ Use the WebAIM Contrast Checker].<br />
## Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?<br />
### Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web.<br />
# Do all videos use subtitles or closed captioning? Are transcripts available for audio content (and do they have timecodes)? Are they automatically generated? Are they accurate? <br />
## Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually.<br />
# Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information.<br />
# Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
## Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Certain users will not have access to the information conveyed in complex images designed to convey information (e.g. screenshots of workflows) if they do not have associated descriptive captions or text.Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
<br />
===Next Steps===<br />
These tasks are more easily accomplished by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually. Please consult the full [https://wiki.diglib.org/Accessibility_Auditing_Resources Accessibility Auditing Resources] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing. These steps have fewer explanatory text because they are geared towards more experienced testers.<br />
<br />
# Perform whatever tests you typically perform while doing an accessibility audit and share your results on the working document, such as using the steps above or an advanced accessibility checker like [https://www.deque.com/axe/ AXE] ([https://www.deque.com/axe/devtools/ browser extension]). Record the results.<br />
# If you have knowledge about VPATs, please share your insights about the VPAT for the service if it exists.<br />
# Does navigation facilitate ease of use?<br />
## Consistent layout and design<br />
## No broken links, or there is a way to report broken links<br />
## Page content hierarchy follows heading guidelines<br />
## Underlined text is avoided unless used for URL navigation<br />
## Is the reading/document order logical and/or natural?<br />
## Is there a “skip to main content” link? Does it go to the most logical “main content?”<br />
# Do images have useful alt text, depending on the context? Do they use a null alt text (alt=””) for decorative images? Refer to the [https://www.w3.org/WAI/tutorials/images/tips/ W3 Image Tutorial Tips and Tricks] for guidance on constructing alt text.<br />
# Does the site properly use [https://accessibility.oit.ncsu.edu/using-aria-landmarks-a-demonstration/ ARIA landmarks]?<br />
# Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
## What barriers are encountered?<br />
## Are any pop-ups or form fields invisible to the screen reader? Do any pop-ups or menus not work with a keyboard?<br />
## Can a user navigate and use the site without using sight?<br />
# Does the page use proper HTML formatting? Ex. Uses H2 instead of bold or a different color of text to create a heading. <br />
# How does the website look or perform on a mobile device browser? Test both Android and iOS.<br />
# Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups?<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. Disabled users are the experts at using their own Assistive Technologies, and can give practical work-arounds that may be missed by other users (especially when they are new to the AT or software, or are stressed out because something isn’t working). <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback.<br />
If you are doing testing at your own organization, it is important to compensate disabled users for their time and expertise. Even if the person is an employee at your organization, if it is not part of their regular duties, they should receive extra compensation.<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
** This wiki uses a basic instance of MediaWiki.<br />
* [https://www.a11yproject.com/ A11y Project]<br />
** This website has several tutorials on accessibility, so you can use it to practice testing while also learning more about accessibility. <br />
* [https://www.w3.org/WAI/demos/bad/before/home.html W3 Example of an Inaccessible Webpage] <br />
** This example website is purposely inaccessible, and includes annotations explaining things, as well as the accessible version<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16624Accessibility Auditing Shortlist2023-11-22T14:30:19Z<p>Dkrahmer: </p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Considerations for non-English and Multilingual items==<br />
The [https://www.w3.org/International/questions/qa-html-language-declarations language of a website or document should be properly declared], including in PDFs and epubs. This tells a screen reader what language the document is in, and that it should switch to a different voice engine. <br />
<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# If the vendor or website has an internal search mechanism (i.e. search box to search the site), test to see if it actually works. You can compare it to a similar search in Google using site searching (add site:website.com to your search string in Google, replacing the address with the top level domain of the site you want to search). <br />
## Rationale: A working internal search can save a user a lot of time and energy if it works. Optimally, you could use the internal search to find the keyboard shortcuts, vpat, or other accessibility information. If the internal search doesn't work, then it's useless to help anyone.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
# Test out basic keyboard-only access to the website.<br />
## Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes? <br />
### Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit [https://nomouse.org/ Take the #NoMouse Challenge] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics].<br />
## Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
### Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.<br />
## Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?<br />
### Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.<br />
## Does the vendor include a list of keyboard shortcuts? Record that information. <br />
## How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?<br />
# Does the website or software require the user to drag-and-drop to do something, without having an alternative?<br />
## Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
# Does the website use color alone to denote meaning? <br />
## Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
## Does being color blind in some way affect a user’s ability to fully use the site? Is there a difference in color between a visited link and a non-visited link?<br />
### Rationale: Using color alone can affect how users who are color blind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
# Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
## Is any information cut off or made incomprehensible or inaccessible?<br />
## Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All?<br />
### Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%.<br />
# Are the links on the website accessible?<br />
## Are the links a different color from the regular text? Are they underlined?<br />
### Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. [https://webaim.org/resources/contrastchecker/ Use the WebAIM Contrast Checker].<br />
## Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?<br />
### Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web.<br />
# Do all videos use subtitles or closed captioning? Are transcripts available for audio content (and do they have timecodes)? Are they automatically generated? Are they accurate? <br />
## Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually.<br />
# Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information.<br />
# Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
## Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Certain users will not have access to the information conveyed in complex images designed to convey information (e.g. screenshots of workflows) if they do not have associated descriptive captions or text.Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
<br />
===Next Steps===<br />
These tasks are more easily accomplished by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually. Please consult the full [https://wiki.diglib.org/Accessibility_Auditing_Resources Accessibility Auditing Resources] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing. These steps have fewer explanatory text because they are geared towards more experienced testers.<br />
<br />
# Perform whatever tests you typically perform while doing an accessibility audit and share your results on the working document, such as using the steps above or an advanced accessibility checker like [https://www.deque.com/axe/ AXE] ([https://www.deque.com/axe/devtools/ browser extension]). Record the results.<br />
# If you have knowledge about VPATs, please share your insights about the VPAT for the service if it exists.<br />
# Does navigation facilitate ease of use?<br />
## Consistent layout and design<br />
## No broken links, or there is a way to report broken links<br />
## Page content hierarchy follows heading guidelines<br />
## Underlined text is avoided unless used for URL navigation<br />
## Is the reading/document order logical and/or natural?<br />
## Is there a “skip to main content” link? Does it go to the most logical “main content?”<br />
# Do images have useful alt text, depending on the context? Do they use a null alt text (alt=””) for decorative images? Refer to the [https://www.w3.org/WAI/tutorials/images/tips/ W3 Image Tutorial Tips and Tricks] for guidance on constructing alt text.<br />
# Does the site properly use [https://accessibility.oit.ncsu.edu/using-aria-landmarks-a-demonstration/ ARIA landmarks]?<br />
# Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
## What barriers are encountered?<br />
## Are any pop-ups or form fields invisible to the screen reader? Do any pop-ups or menus not work with a keyboard?<br />
## Can a user navigate and use the site without using sight?<br />
# Does the page use proper HTML formatting? Ex. Uses H2 instead of bold or a different color of text to create a heading. <br />
# How does the website look or perform on a mobile device browser? Test both Android and iOS.<br />
# Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups?<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. Disabled users are the experts at using their own Assistive Technologies, and can give practical work-arounds that may be missed by other users (especially when they are new to the AT or software, or are stressed out because something isn’t working). <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback.<br />
If you are doing testing at your own organization, it is important to compensate disabled users for their time and expertise. Even if the person is an employee at your organization, if it is not part of their regular duties, they should receive extra compensation.<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
** This wiki uses a basic instance of MediaWiki.<br />
* [https://www.a11yproject.com/ A11y Project]<br />
** This website has several tutorials on accessibility, so you can use it to practice testing while also learning more about accessibility. <br />
* [https://www.w3.org/WAI/demos/bad/before/home.html W3 Example of an Inaccessible Webpage] <br />
** This example website is purposely inaccessible, and includes annotations explaining things, as well as the accessible version<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=PressBooks_Accessibility&diff=16570PressBooks Accessibility2023-08-01T16:23:48Z<p>Dkrahmer: </p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of PressBooks. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
PressBooks is a platform for publishing books online. [https://pressbooks.bccampus.ca/accessibilityhandbook/chapter/wordpress-and-pressbooks/ Built off of WordPress], PressBooks offers online publishing in HTML, with options to make the book downloadable in PDF or EPUB formats. We only tested the authoring side and the public/reader side of PressBooks, and didn't do a deep examination of the PDF or EPUB outputs. As such, we can't comment on the non-HTML outputs available for PressBooks. <br />
<br />
The PressBooks authoring side is '''generally accessible'''. We did not encounter any barriers. However, when it comes to the publishing/reading side of PressBooks, much of the accessibility of a PressBooks book is left up to whoever has authored it. If the author follows best practices, then the resulting book is accessible.<br />
<br />
== General Information ==<br />
<br />
* [https://pressbooks.com/app/uploads/2023/02/Pressbooks-authoring-platform-VPAT-Feb-2023.pdf Authoring VPAT] (pdf)<br />
* [https://pressbooks.com/app/uploads/2023/02/Pressbooks-reading-interface-VPAT-Feb-2023.pdf Reading VPAT] (pdf)<br />
* [https://pressbooks.com/accessibility/ PressBooks' Accessibility Page]<br />
* [https://pressbooks.com/app/uploads/2022/05/Pressbooks-Accessibility-Standards-and-Commitments.pdf PressBooks' Accessibility Standards and Commitments] (pdf)<br />
* [https://kb.iu.edu/d/bgkz Create Accessible Math in PressBooks and Canvas] from Indiana University<br />
* [https://guide.pressbooks.com/chapter/add-mathematical-notation/ Add Mathematical Notation] from the PressBooks accessibility guide<br />
* [https://kb.wisc.edu/accessibility/page.php?id=106296 University of Wisconsin's Accessibility Summary]<br />
* University of Washington's experience [https://opentext.wsu.edu/accessibility-case-studies/chapter/case-study11-uw-pressbooks/ collaborating with PressBooks for greater accessibility]<br />
<br />
<br />
== Known Accessibility Issues ==<br />
<br />
Because so much of the final accessibility of a PressBooks book is up to the author, PressBooks and many universities offer free and open guides to creating accessible books: <br />
* PressBooks's [https://guide.pressbooks.com/chapter/make-your-book-accessible-and-inclusive/ Make Your Book Accessible and Inclusive] user guide<br />
* University of Guelph's [https://guides.lib.uoguelph.ca/accessiblepressbooks Making PressBooks Accessible]<br />
* BCcampus's Free [https://opentextbc.ca/accessibilitytoolkit/ Accessibility Toolkit]<br />
* University of Washington's [https://uw.pressbooks.pub/uwaccessibility/ Teaching, Testing, and Talking Accessibility]<br />
<br />
There are some differences between PressBooks.com and PressBooks.org, as well as between which templates you use for creating your PressBook. <br />
* Different versions of PressBooks use [https://pressbooks.community/t/textbox-accessibility/2371 different heading levels for call-out boxes and other visual text boxes], and will sometimes use no headers at all. You should test your book using a screen reader to make sure it makes sense. <br />
* [https://guide.pressbooks.com/chapter/add-mathematical-notation/ PressBooks.org has native MathJax integration, while PressBooks.com has WordPress's QuickLaTeX as the default for math rendering]. You can also select which plugin you'd rather use in PressBooks.com. If you're using a university's installation of PressBooks, you will need to ask them what they recommend and/or have installed. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=PressBooks_Accessibility&diff=16569PressBooks Accessibility2023-08-01T16:22:00Z<p>Dkrahmer: </p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of PressBooks. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
PressBooks is a platform for publishing books online. [https://pressbooks.bccampus.ca/accessibilityhandbook/chapter/wordpress-and-pressbooks/ Built off of WordPress], PressBooks offers online publishing in HTML, with options to make the book downloadable in PDF or EPUB formats. We only tested the authoring side and the public/reader side of PressBooks, and didn't do a deep examination of the PDF or EPUB outputs. As such, we can't comment on the non-HTML outputs available for PressBooks. <br />
<br />
The PressBooks authoring side is '''generally accessible'''. However, when it comes to the publishing/reading side of PressBooks, much of the accessibility of a PressBooks book is left up to whoever has authored it. If the author follows best practices, then the resulting book is accessible.<br />
<br />
== General Information ==<br />
<br />
* [https://pressbooks.com/app/uploads/2023/02/Pressbooks-authoring-platform-VPAT-Feb-2023.pdf Authoring VPAT] (pdf)<br />
* [https://pressbooks.com/app/uploads/2023/02/Pressbooks-reading-interface-VPAT-Feb-2023.pdf Reading VPAT] (pdf)<br />
* [https://pressbooks.com/accessibility/ PressBooks' Accessibility Page]<br />
* [https://pressbooks.com/app/uploads/2022/05/Pressbooks-Accessibility-Standards-and-Commitments.pdf PressBooks' Accessibility Standards and Commitments] (pdf)<br />
* [https://kb.iu.edu/d/bgkz Create Accessible Math in PressBooks and Canvas] from Indiana University<br />
* [https://guide.pressbooks.com/chapter/add-mathematical-notation/ Add Mathematical Notation] from the PressBooks accessibility guide<br />
* [https://kb.wisc.edu/accessibility/page.php?id=106296 University of Wisconsin's Accessibility Summary]<br />
* University of Washington's experience [https://opentext.wsu.edu/accessibility-case-studies/chapter/case-study11-uw-pressbooks/ collaborating with PressBooks for greater accessibility]<br />
<br />
<br />
== Known Accessibility Issues ==<br />
<br />
Because so much of the final accessibility of a PressBooks book is up to the author, PressBooks and many universities offer free and open guides to creating accessible books: <br />
* PressBooks's [https://guide.pressbooks.com/chapter/make-your-book-accessible-and-inclusive/ Make Your Book Accessible and Inclusive] user guide<br />
* University of Guelph's [https://guides.lib.uoguelph.ca/accessiblepressbooks Making PressBooks Accessible]<br />
* BCcampus's Free [https://opentextbc.ca/accessibilitytoolkit/ Accessibility Toolkit]<br />
* University of Washington's [https://uw.pressbooks.pub/uwaccessibility/ Teaching, Testing, and Talking Accessibility]<br />
<br />
There are some differences between PressBooks.com and PressBooks.org, as well as between which templates you use for creating your PressBook. <br />
* Different versions of PressBooks use [https://pressbooks.community/t/textbox-accessibility/2371 different heading levels for call-out boxes and other visual text boxes], and will sometimes use no headers at all. You should test your book using a screen reader to make sure it makes sense. <br />
* [https://guide.pressbooks.com/chapter/add-mathematical-notation/ PressBooks.org has native MathJax integration, while PressBooks.com has WordPress's QuickLaTeX as the default for math rendering]. You can also select which plugin you'd rather use in PressBooks.com. If you're using a university's installation of PressBooks, you will need to ask them what they recommend and/or have installed. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=PressBooks_Accessibility&diff=16568PressBooks Accessibility2023-08-01T16:17:47Z<p>Dkrahmer: </p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of PressBooks. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
PressBooks is a platform for publishing books online. [https://pressbooks.bccampus.ca/accessibilityhandbook/chapter/wordpress-and-pressbooks/ Built off of WordPress], PressBooks offers online publishing in HTML, with options to make the book downloadable in PDF or EPUB formats. We only tested the authoring side and the public/reader side of PressBooks, and didn't do a deep examination of the PDF or EPUB outputs. As such, we can't comment on the non-HTML outputs available for PressBooks. <br />
<br />
The PressBooks authoring side is '''generally accessible'''. However, when it comes to the publishing/reading side of PressBooks, much of the accessibility of a PressBooks book is left up to whoever has authored it. If the author follows best practices, then the resulting book is accessible.<br />
<br />
== General Information ==<br />
<br />
* [https://pressbooks.com/app/uploads/2023/02/Pressbooks-authoring-platform-VPAT-Feb-2023.pdf Authoring VPAT] (pdf)<br />
* [https://pressbooks.com/app/uploads/2023/02/Pressbooks-reading-interface-VPAT-Feb-2023.pdf Reading VPAT] (pdf)<br />
* [https://pressbooks.com/accessibility/ PressBooks' Accessibility Page]<br />
* [https://pressbooks.com/app/uploads/2022/05/Pressbooks-Accessibility-Standards-and-Commitments.pdf PressBooks' Accessibility Standards and Commitments] (pdf)<br />
* [https://kb.iu.edu/d/bgkz Create Accessible Math in PressBooks and Canvas] from Indiana University<br />
* [https://guide.pressbooks.com/chapter/add-mathematical-notation/ Add Mathematical Notation] from the PressBooks accessibility guide<br />
<br />
<br />
<br />
<br />
<br />
<br />
== Known Accessibility Issues ==<br />
<br />
Because so much of the final accessibility of a PressBooks book is up to the author, PressBooks and many universities offer free and open guides to creating accessible books: <br />
* PressBooks's [https://guide.pressbooks.com/chapter/make-your-book-accessible-and-inclusive/ Make Your Book Accessible and Inclusive] user guide<br />
* University of Guelph's [https://guides.lib.uoguelph.ca/accessiblepressbooks Making PressBooks Accessible]<br />
<br />
There are some differences between PressBooks.com and PressBooks.org, as well as between which templates you use for creating your PressBook. <br />
* Different versions of PressBooks use [https://pressbooks.community/t/textbox-accessibility/2371 different heading levels for call-out boxes and other visual text boxes], and will sometimes use no headers at all. You should test your book using a screen reader to make sure it makes sense. <br />
* [https://guide.pressbooks.com/chapter/add-mathematical-notation/ PressBooks.org has native MathJax integration, while PressBooks.com has WordPress's QuickLaTeX as the default for math rendering]. You can also select which plugin you'd rather use in PressBooks.com. If you're using a university's installation of PressBooks, you will need to ask them what they recommend and/or have installed. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=PressBooks_Accessibility&diff=16567PressBooks Accessibility2023-08-01T15:58:05Z<p>Dkrahmer: /* General Information */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of PressBooks. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
PressBooks is a platform for publishing books online. [https://pressbooks.bccampus.ca/accessibilityhandbook/chapter/wordpress-and-pressbooks/ Built off of WordPress], PressBooks offers online publishing in HTML, with options to make the book downloadable in PDF or EPUB formats. We only tested the authoring side and the public/reader side of PressBooks, and didn't do a deep examination of the PDF or EPUB outputs. As such, we can't comment on the non-HTML outputs available for PressBooks. <br />
<br />
The PressBooks authoring side is '''generally accessible'''. However, when it comes to the publishing/reading side of PressBooks, much of the accessibility of a PressBooks book is left up to whoever has authored it. If the author follows best practices, then the resulting book is accessible.<br />
<br />
== General Information ==<br />
<br />
* [https://pressbooks.com/app/uploads/2023/02/Pressbooks-authoring-platform-VPAT-Feb-2023.pdf Authoring VPAT] (pdf)<br />
* [https://pressbooks.com/app/uploads/2023/02/Pressbooks-reading-interface-VPAT-Feb-2023.pdf Reading VPAT] (pdf)<br />
* [https://pressbooks.com/accessibility/ PressBooks' Accessibility Page]<br />
* [https://pressbooks.com/app/uploads/2022/05/Pressbooks-Accessibility-Standards-and-Commitments.pdf PressBooks' Accessibility Standards and Commitments] (pdf)<br />
<br />
<br />
<br />
Because so much of the final accessibility of a PressBooks book is up to the author, PressBooks and many universities offer free and open guides to creating accessible books: <br />
* PressBooks's [https://guide.pressbooks.com/chapter/make-your-book-accessible-and-inclusive/ Make Your Book Accessible and Inclusive] user guide<br />
* University of Guelph's [https://guides.lib.uoguelph.ca/accessiblepressbooks Making PressBooks Accessible]<br />
<br />
== Known Accessibility Issues ==<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=PressBooks_Accessibility&diff=16566PressBooks Accessibility2023-08-01T15:53:20Z<p>Dkrahmer: </p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of PressBooks. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
PressBooks is a platform for publishing books online. [https://pressbooks.bccampus.ca/accessibilityhandbook/chapter/wordpress-and-pressbooks/ Built off of WordPress], PressBooks offers online publishing in HTML, with options to make the book downloadable in PDF or EPUB formats. We only tested the authoring side and the public/reader side of PressBooks, and didn't do a deep examination of the PDF or EPUB outputs. As such, we can't comment on the non-HTML outputs available for PressBooks. <br />
<br />
The PressBooks authoring side is '''generally accessible'''. However, when it comes to the publishing/reading side of PressBooks, much of the accessibility of a PressBooks book is left up to whoever has authored it. If the author follows best practices, then the resulting book is accessible.<br />
<br />
== General Information ==<br />
<br />
* [https://pressbooks.com/app/uploads/2023/02/Pressbooks-authoring-platform-VPAT-Feb-2023.pdf Authoring VPAT] (pdf)<br />
* [https://pressbooks.com/app/uploads/2023/02/Pressbooks-reading-interface-VPAT-Feb-2023.pdf Reading VPAT] (pdf)<br />
* [https://pressbooks.com/accessibility/ PressBooks' Accessibility Page]<br />
* [https://pressbooks.com/app/uploads/2022/05/Pressbooks-Accessibility-Standards-and-Commitments.pdf PressBooks' Accessibility Standards and Commitments] (pdf)<br />
<br />
<br />
<br />
Because so much of the final accessibility of a PressBooks book is up to the author, PressBooks and many universities offer free and open guides to creating accessible books: <br />
* PressBooks's [https://guide.pressbooks.com/chapter/make-your-book-accessible-and-inclusive/ Make Your Book Accessible and Inclusive] user guide<br />
* <br />
<br />
== Known Accessibility Issues ==<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=PressBooks_Accessibility&diff=16565PressBooks Accessibility2023-08-01T15:48:43Z<p>Dkrahmer: /* Known Accessibility Issues */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of PressBooks. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
PressBooks is a platform for publishing books online. Built off of WordPress, PressBooks offers online publishing in HTML, with options to make the book downloadable in PDF or EPUB formats. We only tested the authoring side and the public/reader side of PressBooks, and didn't do a deep examination of the PDF or EPUB outputs. As such, we can't comment on the non-HTML outputs available for PressBooks. <br />
<br />
The PressBooks authoring side is '''generally accessible'''. However, when it comes to the publishing/reading side of PressBooks, much of the accessibility of a PressBooks book is left up to whoever has authored it. If the author follows best practices, then the resulting book is accessible.<br />
<br />
== General Information ==<br />
<br />
== Known Accessibility Issues ==<br />
<br />
Because so much of the final accessibility of a PressBooks book is up to the author, PressBooks and many universities offer free and open guides to creating accessible books: <br />
* PressBooks's [https://guide.pressbooks.com/chapter/make-your-book-accessible-and-inclusive/ Make Your Book Accessible and Inclusive] user guide<br />
<br />
<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=PressBooks_Accessibility&diff=16564PressBooks Accessibility2023-08-01T15:44:14Z<p>Dkrahmer: /* Accessibility Overview */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of PressBooks. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
PressBooks is a platform for publishing books online. Built off of WordPress, PressBooks offers online publishing in HTML, with options to make the book downloadable in PDF or EPUB formats. We only tested the authoring side and the public/reader side of PressBooks, and didn't do a deep examination of the PDF or EPUB outputs. As such, we can't comment on the non-HTML outputs available for PressBooks. <br />
<br />
The PressBooks authoring side is '''generally accessible'''. However, when it comes to the publishing/reading side of PressBooks, much of the accessibility of a PressBooks book is left up to whoever has authored it. If the author follows best practices, then the resulting book is accessible.<br />
<br />
== General Information ==<br />
<br />
== Known Accessibility Issues ==<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=PressBooks_Accessibility&diff=16563PressBooks Accessibility2023-07-31T19:00:02Z<p>Dkrahmer: Created page with "This page gathers the IT Subcommittee's resources and reviews of the accessibility of PressBooks. This page will be updated as new information is available or further reviews are conducted. == Accessibility Overview == == General Information == == Known Accessibility Issues == * Back to main Digital Accessibility Group page."</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of PressBooks. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
== General Information ==<br />
<br />
== Known Accessibility Issues ==<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=IT_and_Development&diff=16562IT and Development2023-07-31T16:57:47Z<p>Dkrahmer: /* Accessibility Audits */</p>
<hr />
<div>The IT and Development subgroup will focus on specific software, hardware, and development practices associated with information organizations. Once a list of technologies associated with specific areas is compiled, they will begin addressing the accessibility concerns of specific entries. We adhere to the same mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group]. <br />
<br />
==Monthly Meetings==<br />
<br />
For 2023, the DLF DAWG-IT subgroup is focusing on updating our documentation and assessing the accessibility of other GLAM technologies.<br />
<br />
Meetings will be held on the final Monday of the month, at 11:15am Eastern/3:15pm GMT. ([https://www.thetimezoneconverter.com/ Timezone converter]) Check the [https://docs.google.com/document/d/1yXEgjUEdUfu5ORBOAOLvdBNZqFHpQOxTULxcvy4EfCc/edit 2023 running agenda] for more information, including links to register for the meetings.<br />
<br />
== Completed Projects ==<br />
* [[Accessible Documentation]]<br />
* [[Accessibility Auditing Resources]]<br />
* [[Accessibility Auditing Shortlist]]<br />
* [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit?usp=sharing Accessibility Auditing Template] Google Doc. Make a copy to start your own evaluation.<br />
<br />
== Accessibility Audits ==<br />
In 2021, the DAWG-IT subgroup focused on accessibility testing of the software typically used for DAWG meetings and events. For 2022, we focused on broader GLAM software. In 2023, we updated our Auditing Shortlist and continue to test GLAM applications. These are our completed audits:<br />
<br />
* [[Zoom Accessibility]]<br />
* [[Doodle.com Accessibility]]<br />
* [[Google Forms Accessibility]]<br />
* [[Otter.ai Accessibility]]<br />
* [[Google Docs Accessibility]]<br />
* [[Google Slides Accessibility]]<br />
* [[Zotero Accessibility]]<br />
* [[Online Conference Platforms Accessibility]]<br />
* [[ArchivesSpace Accessibility]]<br />
* [[AirTable Accessibility]]<br />
* [[PressBooks Accessibility]]<br />
<br />
== Group Organizers ==<br />
* Debbie Krahmer dkrahmer AT cornell.edu<br />
<br />
== Members ==<br />
* Ima Odouk<br />
* Elliot Stevens<br />
* Wendy Robertson<br />
* Kristen Heldmann<br />
* Gabe Galson<br />
* Hannah Sistrunk<br />
* Rita Johnston<br />
* Penniphurr Stevenson<br />
* Eudora Struble<br />
* Deseree Stukes<br />
* Jonathan Milam<br />
<br />
== Future Technologies to Research ==<br />
Everyone is welcome to participate, regardless of your own personal level of skill with accessibility auditing. We've compiled an [[Accessibility Auditing Shortlist]] that anyone can use to contribute to the knowledge base. The ultimate goal for all of these audits is to make the information freely available to anyone. Google docs is currently used for the initial working document before moving information to the wiki. Contact the Organizers for information on how to join the community and get wiki editing access.<br />
<br />
* [https://docs.google.com/document/d/1gAS04mUZSM7g1VBcF5kfry0uuHqvMQc21nXso20h5Pg/edit?usp=sharing Google Sheets]<br />
* [https://docs.google.com/document/d/1vGJey7_KQdM0lLYAdt9W8DkiuWaJXKF-BuvDulsUMbA/edit?usp=sharing Slack]<br />
* OJS, open journal systems<br />
* Institutional Repositories (bepress, DSpace, etc.)<br />
* DAMs (Contentdm, Islandora, etc.)<br />
* Library Systems<br />
* Virtual Tours<br />
* Digital Scholarship (Research data, tools, visualizations)<br />
* Databases and Vendors<br />
* Virtual Reality (3D technologies, including Makerspace equipment)<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=IT_and_Development&diff=16556IT and Development2023-07-05T15:48:56Z<p>Dkrahmer: /* Monthly Meetings */</p>
<hr />
<div>The IT and Development subgroup will focus on specific software, hardware, and development practices associated with information organizations. Once a list of technologies associated with specific areas is compiled, they will begin addressing the accessibility concerns of specific entries. We adhere to the same mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group]. <br />
<br />
==Monthly Meetings==<br />
<br />
For 2023, the DLF DAWG-IT subgroup is focusing on updating our documentation and assessing the accessibility of other GLAM technologies.<br />
<br />
Meetings will be held on the final Monday of the month, at 11:15am Eastern/3:15pm GMT. ([https://www.thetimezoneconverter.com/ Timezone converter]) Check the [https://docs.google.com/document/d/1yXEgjUEdUfu5ORBOAOLvdBNZqFHpQOxTULxcvy4EfCc/edit 2023 running agenda] for more information, including links to register for the meetings.<br />
<br />
== Completed Projects ==<br />
* [[Accessible Documentation]]<br />
* [[Accessibility Auditing Resources]]<br />
* [[Accessibility Auditing Shortlist]]<br />
* [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit?usp=sharing Accessibility Auditing Template] Google Doc. Make a copy to start your own evaluation.<br />
<br />
== Accessibility Audits ==<br />
In 2021, the DAWG-IT subgroup focused on accessibility testing of the software typically used for DAWG meetings and events. For 2022, we focused on broader GLAM software. In 2023, we updated our Auditing Shortlist and continue to test GLAM applications. These are our completed audits:<br />
<br />
* [[Zoom Accessibility]]<br />
* [[Doodle.com Accessibility]]<br />
* [[Google Forms Accessibility]]<br />
* [[Otter.ai Accessibility]]<br />
* [[Google Docs Accessibility]]<br />
* [[Google Slides Accessibility]]<br />
* [[Zotero Accessibility]]<br />
* [[Online Conference Platforms Accessibility]]<br />
* [[ArchivesSpace Accessibility]]<br />
* [[AirTable Accessibility]]<br />
<br />
== Group Organizers ==<br />
* Debbie Krahmer dkrahmer AT cornell.edu<br />
<br />
== Members ==<br />
* Ima Odouk<br />
* Elliot Stevens<br />
* Wendy Robertson<br />
* Kristen Heldmann<br />
* Gabe Galson<br />
* Hannah Sistrunk<br />
* Rita Johnston<br />
* Penniphurr Stevenson<br />
* Eudora Struble<br />
* Deseree Stukes<br />
* Jonathan Milam<br />
<br />
== Future Technologies to Research ==<br />
Everyone is welcome to participate, regardless of your own personal level of skill with accessibility auditing. We've compiled an [[Accessibility Auditing Shortlist]] that anyone can use to contribute to the knowledge base. The ultimate goal for all of these audits is to make the information freely available to anyone. Google docs is currently used for the initial working document before moving information to the wiki. Contact the Organizers for information on how to join the community and get wiki editing access.<br />
<br />
* [https://docs.google.com/document/d/1gAS04mUZSM7g1VBcF5kfry0uuHqvMQc21nXso20h5Pg/edit?usp=sharing Google Sheets]<br />
* [https://docs.google.com/document/d/1vGJey7_KQdM0lLYAdt9W8DkiuWaJXKF-BuvDulsUMbA/edit?usp=sharing Slack]<br />
* OJS, open journal systems<br />
* Institutional Repositories (bepress, DSpace, etc.)<br />
* DAMs (Contentdm, Islandora, etc.)<br />
* Library Systems<br />
* Virtual Tours<br />
* Digital Scholarship (Research data, tools, visualizations)<br />
* Databases and Vendors<br />
* Virtual Reality (3D technologies, including Makerspace equipment)<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=IT_and_Development&diff=16555IT and Development2023-07-05T15:48:39Z<p>Dkrahmer: /* Monthly Meetings */</p>
<hr />
<div>The IT and Development subgroup will focus on specific software, hardware, and development practices associated with information organizations. Once a list of technologies associated with specific areas is compiled, they will begin addressing the accessibility concerns of specific entries. We adhere to the same mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group]. <br />
<br />
==Monthly Meetings==<br />
<br />
For 2023, the DLF DAWG-IT subgroup is focusing on assessing the accessibility of other GLAM technologies.<br />
<br />
Meetings will be held on the final Monday of the month, at 11:15am Eastern/3:15pm GMT. ([https://www.thetimezoneconverter.com/ Timezone converter]) Check the [https://docs.google.com/document/d/1yXEgjUEdUfu5ORBOAOLvdBNZqFHpQOxTULxcvy4EfCc/edit 2023 running agenda] for more information, including links to register for the meetings.<br />
<br />
== Completed Projects ==<br />
* [[Accessible Documentation]]<br />
* [[Accessibility Auditing Resources]]<br />
* [[Accessibility Auditing Shortlist]]<br />
* [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit?usp=sharing Accessibility Auditing Template] Google Doc. Make a copy to start your own evaluation.<br />
<br />
== Accessibility Audits ==<br />
In 2021, the DAWG-IT subgroup focused on accessibility testing of the software typically used for DAWG meetings and events. For 2022, we focused on broader GLAM software. In 2023, we updated our Auditing Shortlist and continue to test GLAM applications. These are our completed audits:<br />
<br />
* [[Zoom Accessibility]]<br />
* [[Doodle.com Accessibility]]<br />
* [[Google Forms Accessibility]]<br />
* [[Otter.ai Accessibility]]<br />
* [[Google Docs Accessibility]]<br />
* [[Google Slides Accessibility]]<br />
* [[Zotero Accessibility]]<br />
* [[Online Conference Platforms Accessibility]]<br />
* [[ArchivesSpace Accessibility]]<br />
* [[AirTable Accessibility]]<br />
<br />
== Group Organizers ==<br />
* Debbie Krahmer dkrahmer AT cornell.edu<br />
<br />
== Members ==<br />
* Ima Odouk<br />
* Elliot Stevens<br />
* Wendy Robertson<br />
* Kristen Heldmann<br />
* Gabe Galson<br />
* Hannah Sistrunk<br />
* Rita Johnston<br />
* Penniphurr Stevenson<br />
* Eudora Struble<br />
* Deseree Stukes<br />
* Jonathan Milam<br />
<br />
== Future Technologies to Research ==<br />
Everyone is welcome to participate, regardless of your own personal level of skill with accessibility auditing. We've compiled an [[Accessibility Auditing Shortlist]] that anyone can use to contribute to the knowledge base. The ultimate goal for all of these audits is to make the information freely available to anyone. Google docs is currently used for the initial working document before moving information to the wiki. Contact the Organizers for information on how to join the community and get wiki editing access.<br />
<br />
* [https://docs.google.com/document/d/1gAS04mUZSM7g1VBcF5kfry0uuHqvMQc21nXso20h5Pg/edit?usp=sharing Google Sheets]<br />
* [https://docs.google.com/document/d/1vGJey7_KQdM0lLYAdt9W8DkiuWaJXKF-BuvDulsUMbA/edit?usp=sharing Slack]<br />
* OJS, open journal systems<br />
* Institutional Repositories (bepress, DSpace, etc.)<br />
* DAMs (Contentdm, Islandora, etc.)<br />
* Library Systems<br />
* Virtual Tours<br />
* Digital Scholarship (Research data, tools, visualizations)<br />
* Databases and Vendors<br />
* Virtual Reality (3D technologies, including Makerspace equipment)<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=IT_and_Development&diff=16554IT and Development2023-07-05T15:48:12Z<p>Dkrahmer: /* Monthly Meetings */</p>
<hr />
<div>The IT and Development subgroup will focus on specific software, hardware, and development practices associated with information organizations. Once a list of technologies associated with specific areas is compiled, they will begin addressing the accessibility concerns of specific entries. We adhere to the same mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group]. <br />
<br />
==Monthly Meetings==<br />
<br />
For 2023, the DLF DAWG-IT subgroup is moving on from testing the software used by our parent organization and instead will focus on assessing the accessibility of other GLAM technologies.<br />
<br />
Meetings will be held on the final Monday of the month, at 11:15am Eastern/3:15pm GMT. ([https://www.thetimezoneconverter.com/ Timezone converter]) Check the [https://docs.google.com/document/d/1yXEgjUEdUfu5ORBOAOLvdBNZqFHpQOxTULxcvy4EfCc/edit 2023 running agenda] for more information, including links to register for the meetings.<br />
<br />
== Completed Projects ==<br />
* [[Accessible Documentation]]<br />
* [[Accessibility Auditing Resources]]<br />
* [[Accessibility Auditing Shortlist]]<br />
* [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit?usp=sharing Accessibility Auditing Template] Google Doc. Make a copy to start your own evaluation.<br />
<br />
== Accessibility Audits ==<br />
In 2021, the DAWG-IT subgroup focused on accessibility testing of the software typically used for DAWG meetings and events. For 2022, we focused on broader GLAM software. In 2023, we updated our Auditing Shortlist and continue to test GLAM applications. These are our completed audits:<br />
<br />
* [[Zoom Accessibility]]<br />
* [[Doodle.com Accessibility]]<br />
* [[Google Forms Accessibility]]<br />
* [[Otter.ai Accessibility]]<br />
* [[Google Docs Accessibility]]<br />
* [[Google Slides Accessibility]]<br />
* [[Zotero Accessibility]]<br />
* [[Online Conference Platforms Accessibility]]<br />
* [[ArchivesSpace Accessibility]]<br />
* [[AirTable Accessibility]]<br />
<br />
== Group Organizers ==<br />
* Debbie Krahmer dkrahmer AT cornell.edu<br />
<br />
== Members ==<br />
* Ima Odouk<br />
* Elliot Stevens<br />
* Wendy Robertson<br />
* Kristen Heldmann<br />
* Gabe Galson<br />
* Hannah Sistrunk<br />
* Rita Johnston<br />
* Penniphurr Stevenson<br />
* Eudora Struble<br />
* Deseree Stukes<br />
* Jonathan Milam<br />
<br />
== Future Technologies to Research ==<br />
Everyone is welcome to participate, regardless of your own personal level of skill with accessibility auditing. We've compiled an [[Accessibility Auditing Shortlist]] that anyone can use to contribute to the knowledge base. The ultimate goal for all of these audits is to make the information freely available to anyone. Google docs is currently used for the initial working document before moving information to the wiki. Contact the Organizers for information on how to join the community and get wiki editing access.<br />
<br />
* [https://docs.google.com/document/d/1gAS04mUZSM7g1VBcF5kfry0uuHqvMQc21nXso20h5Pg/edit?usp=sharing Google Sheets]<br />
* [https://docs.google.com/document/d/1vGJey7_KQdM0lLYAdt9W8DkiuWaJXKF-BuvDulsUMbA/edit?usp=sharing Slack]<br />
* OJS, open journal systems<br />
* Institutional Repositories (bepress, DSpace, etc.)<br />
* DAMs (Contentdm, Islandora, etc.)<br />
* Library Systems<br />
* Virtual Tours<br />
* Digital Scholarship (Research data, tools, visualizations)<br />
* Databases and Vendors<br />
* Virtual Reality (3D technologies, including Makerspace equipment)<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=IT_and_Development&diff=16553IT and Development2023-07-05T15:03:49Z<p>Dkrahmer: /* Accessibility Audits */</p>
<hr />
<div>The IT and Development subgroup will focus on specific software, hardware, and development practices associated with information organizations. Once a list of technologies associated with specific areas is compiled, they will begin addressing the accessibility concerns of specific entries. We adhere to the same mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group]. <br />
<br />
==Monthly Meetings==<br />
<br />
For 2023, the DLF DAWG-IT subgroup is moving on from testing the software used by our parent organization and instead will focus on assessing the accessibility of other GLAM technologies. Our initial focus was on [[Zotero Accessibility|Zotero]]. We're collaborating with a group of librarians in Canada who are already pushing for more accessibility within Zotero.<br />
<br />
Then we will move on to [https://docs.google.com/document/d/1SoJnsOdUPzE-m7tEbx11uFQ-cxO69YkYLHvXnElM6lA/edit?usp=sharing Online conference platforms]. We've collected notes over the past two years about accessibility issues, and will figure out how to place it into a more useful document for the future. <br />
<br />
Meetings will be held on the final Monday of the month, at 11:15am Eastern/3:15pm GMT. ([https://www.thetimezoneconverter.com/ Timezone converter]) Check the [https://docs.google.com/document/d/1yXEgjUEdUfu5ORBOAOLvdBNZqFHpQOxTULxcvy4EfCc/edit 2023 running agenda] for more information, including links to register for the meetings.<br />
<br />
== Completed Projects ==<br />
* [[Accessible Documentation]]<br />
* [[Accessibility Auditing Resources]]<br />
* [[Accessibility Auditing Shortlist]]<br />
* [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit?usp=sharing Accessibility Auditing Template] Google Doc. Make a copy to start your own evaluation.<br />
<br />
== Accessibility Audits ==<br />
In 2021, the DAWG-IT subgroup focused on accessibility testing of the software typically used for DAWG meetings and events. For 2022, we focused on broader GLAM software. In 2023, we updated our Auditing Shortlist and continue to test GLAM applications. These are our completed audits:<br />
<br />
* [[Zoom Accessibility]]<br />
* [[Doodle.com Accessibility]]<br />
* [[Google Forms Accessibility]]<br />
* [[Otter.ai Accessibility]]<br />
* [[Google Docs Accessibility]]<br />
* [[Google Slides Accessibility]]<br />
* [[Zotero Accessibility]]<br />
* [[Online Conference Platforms Accessibility]]<br />
* [[ArchivesSpace Accessibility]]<br />
* [[AirTable Accessibility]]<br />
<br />
== Group Organizers ==<br />
* Debbie Krahmer dkrahmer AT cornell.edu<br />
<br />
== Members ==<br />
* Ima Odouk<br />
* Elliot Stevens<br />
* Wendy Robertson<br />
* Kristen Heldmann<br />
* Gabe Galson<br />
* Hannah Sistrunk<br />
* Rita Johnston<br />
* Penniphurr Stevenson<br />
* Eudora Struble<br />
* Deseree Stukes<br />
* Jonathan Milam<br />
<br />
== Future Technologies to Research ==<br />
Everyone is welcome to participate, regardless of your own personal level of skill with accessibility auditing. We've compiled an [[Accessibility Auditing Shortlist]] that anyone can use to contribute to the knowledge base. The ultimate goal for all of these audits is to make the information freely available to anyone. Google docs is currently used for the initial working document before moving information to the wiki. Contact the Organizers for information on how to join the community and get wiki editing access.<br />
<br />
* [https://docs.google.com/document/d/1gAS04mUZSM7g1VBcF5kfry0uuHqvMQc21nXso20h5Pg/edit?usp=sharing Google Sheets]<br />
* [https://docs.google.com/document/d/1vGJey7_KQdM0lLYAdt9W8DkiuWaJXKF-BuvDulsUMbA/edit?usp=sharing Slack]<br />
* OJS, open journal systems<br />
* Institutional Repositories (bepress, DSpace, etc.)<br />
* DAMs (Contentdm, Islandora, etc.)<br />
* Library Systems<br />
* Virtual Tours<br />
* Digital Scholarship (Research data, tools, visualizations)<br />
* Databases and Vendors<br />
* Virtual Reality (3D technologies, including Makerspace equipment)<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=AirTable_Accessibility&diff=16552AirTable Accessibility2023-06-28T18:48:58Z<p>Dkrahmer: /* Known Accessibility Issues */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of AirTable. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
In general, AirTable is '''not accessible''' in the free version we tested. There are several barriers for anyone using Assistive Technologies, especially screen readers. It's a visually-heavy website that can be cognitively complex. We tested the backend of a free version to create a database, as well as some of the outputs of AirTable.<br />
<br />
== General Information ==<br />
<br />
* [https://support.airtable.com/docs/airtable-keyboard-shortcuts AirTable Keyboard Shortcuts]<br />
* [https://community.airtable.com/t5/other-questions/airtable-accessibility/td-p/130946 An interesting post on the community forum] about accessibility issues from 2020, featuring Michael Cyr from EDUCAUSE ITAccess group. <br />
* [https://community.airtable.com/t5/product-ideas/make-share-views-and-forms-accessible-to-aa-wcag-standards/idi-p/26542 Another forum post] from 2021 about accessibility issues in sharing and form formats. <br />
* [https://community.airtable.com/t5/product-ideas/accessibility-improvements-form/idi-p/120393 A forum post] that suggestions JotForm can be integrated to deal with some accessibility issues. <br />
* [https://wiki.fluidproject.org/display/fluid/Exploration+of+Airtable+for+use+with+Legal+Capacity+Inclusion+Lens A wiki post] outlining several issues that came up in testing AirTable in January 2022. <br />
* [https://www.businesshub.london/accessibility/ Businesshub is a website that uses AirTable,] but notes that it's not accessible to screen readers.<br />
* [https://gist.github.com/jlengstorf/a5a3a57b7b8475d2d00e3e58fc4d9eef Github post with markup changes] to improve accessibility.<br />
<br />
== Known Accessibility Issues ==<br />
<br />
=== Keyboard Control ===<br />
<br />
You cannot use a keyboard only to navigate the website. Several of the menus require the use of a mouse to activate options. The keyboard shortcuts page is inaccessible, and the keyboard shortcuts aren't usable if you depend on a screen reader. Tabbing for navigation also doesn't follow the logical order of visual elements; for example, when trying to create a gallery, the four items tab in the order of "2, 3, 4, 1" rather than "1, 2, 3, 4." Additionally, when you first set up an account, the welcome pop-up cannot be accessed or closed using just the keyboard. It covers the entire page, and cannot be "ESC"d out of, either. Several times pop-ups appeared that required a mouse.<br />
<br />
One good point is that the Customize Cards setting allows for drag-and-drop using a keyboard. <br />
<br />
=== Screen Reader ===<br />
<br />
You cannot use AirTable if you are screen reader dependent. If you use a screen reader to augment low vision, you may be able to use some aspects of AirTable. Most of the buttons are not labeled, and there is no consistent use of headings. For example, in the Kanban view of a base, every element, including the tags, were all at heading level 1. The home screen includes two headers labeled "Home." The Project Tracker template has no labeled elements, and no way of knowing when you've reached the bottom of the page as a screen reader gets stuck in an endless loop around the two active elements on the page (these elements only said "open block view" and "expand extension options"). <br />
<br />
There is no usable alt text on images. Hidden spacer images are used and are not labeled, so there are many phantom "graphic" or "image" elements that appear on the page. Graphs are also not labeled and have no alternative text. It is unclear as a screen reader user how to get to the data contained within the graphs.<br />
<br />
=== Zoom, Text Size and Color Contrast ===<br />
<br />
AirTable becomes unusable at 300% zoom. At 200%, the side menu collapses into a hamburger menu that can't be used with a screen reader or keyboard, and any popups are cut off by the screen and can't be scrolled. <br />
<br />
Several areas of the interface uses very small text, and nearly every page had low-contrast errors coming up. The main text in some areas appears to be a medium gray instead of black. The main area where color blindness will inhibit use of the site were the charts and graphs sections. <br />
<br />
=== Contact Support ===<br />
<br />
AirTable no longer allows for questions to be emailed directly to support. You must go through the Help Menu in the AirTable interface and select "Message Support." Unfortunately, this action is impossible if you are screen reader dependent or only use the keyboard, as menu items cannot be navigated or selected through the keyboard. AirTable uses a chatbot to do a first-run of any questions, but our experiences with asking it questions is that it would give completely irrelevant information. You must use a mouse to select "talk to an agent;" again, making it impossible for a screen reader user to get help. They also direct users to their forums to ask questions, but a quick search (including the "General Information" links above) show that many questions remain unanswered, or are met with strangely aggressive resistance from other users.<br />
<br />
While it is understandable to ask individuals to create an account before reporting a problem to the support people, the lack of accessibility in these options limits the ability of some disabled users to ask for help or report accessibility issues. We are hoping our connection to the support group (developed through attending an AirTable training webinar) will allow us to report these issues and suggest an alternative or focused accessibility issue report form that is accessible.<br />
<br />
=== AirTable Outputs ===<br />
<br />
AirTable is often used to organize conferences for GLAM groups. Overall, the default embedded AirTable Table is not accessible. It is impossible to keyboard navigate the Table, and the Table is not set up for screen reader accessibility. It's the equivalent of taking a screen cap of a table and expecting everyone to be able to read it and use it. All functionality of the Table, such as sorting, is not accessible. The backend is not accessible to keyboard navigation or screen readers. <br />
<br />
AirTable has been used to create forms for voting. These forms are often accessible, or only have a few labelling errors. If elements of the form are required, that information is not shared with the screen reader. <br />
<br />
For example, in preparation for the DLF Forum 2023, AirTable was used to create a form for the community to vote on sessions. The form itself was accessible, but the Table display of all the session descriptions were not. An alternative Google Sheet had to be developed for BVI users. <br />
<br />
Another example was the AirTable uses for ACRL 2021, which was completely inaccessible. Individuals had to request to be sent a spreadsheet of events and information in order to receive the same information that was only available through an AirTable. <br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=AirTable_Accessibility&diff=16551AirTable Accessibility2023-06-28T18:40:34Z<p>Dkrahmer: /* Known Accessibility Issues */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of AirTable. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
In general, AirTable is '''not accessible''' in the free version we tested. There are several barriers for anyone using Assistive Technologies, especially screen readers. It's a visually-heavy website that can be cognitively complex. We tested the backend of a free version to create a database, as well as some of the outputs of AirTable.<br />
<br />
== General Information ==<br />
<br />
* [https://support.airtable.com/docs/airtable-keyboard-shortcuts AirTable Keyboard Shortcuts]<br />
* [https://community.airtable.com/t5/other-questions/airtable-accessibility/td-p/130946 An interesting post on the community forum] about accessibility issues from 2020, featuring Michael Cyr from EDUCAUSE ITAccess group. <br />
* [https://community.airtable.com/t5/product-ideas/make-share-views-and-forms-accessible-to-aa-wcag-standards/idi-p/26542 Another forum post] from 2021 about accessibility issues in sharing and form formats. <br />
* [https://community.airtable.com/t5/product-ideas/accessibility-improvements-form/idi-p/120393 A forum post] that suggestions JotForm can be integrated to deal with some accessibility issues. <br />
* [https://wiki.fluidproject.org/display/fluid/Exploration+of+Airtable+for+use+with+Legal+Capacity+Inclusion+Lens A wiki post] outlining several issues that came up in testing AirTable in January 2022. <br />
* [https://www.businesshub.london/accessibility/ Businesshub is a website that uses AirTable,] but notes that it's not accessible to screen readers.<br />
* [https://gist.github.com/jlengstorf/a5a3a57b7b8475d2d00e3e58fc4d9eef Github post with markup changes] to improve accessibility.<br />
<br />
== Known Accessibility Issues ==<br />
<br />
=== Keyboard Control ===<br />
<br />
You cannot use a keyboard only to navigate the website. Several of the menus require the use of a mouse to activate options. The keyboard shortcuts page is inaccessible, and the keyboard shortcuts aren't usable if you depend on a screen reader. Tabbing for navigation also doesn't follow the logical order of visual elements; for example, when trying to create a gallery, the four items tab in the order of "2, 3, 4, 1" rather than "1, 2, 3, 4." Additionally, when you first set up an account, the welcome pop-up cannot be accessed or closed using just the keyboard. It covers the entire page, and cannot be "ESC"d out of, either. Several times pop-ups appeared that required a mouse.<br />
<br />
One good point is that the Customize Cards setting allows for drag-and-drop using a keyboard. <br />
<br />
=== Screen Reader ===<br />
<br />
You cannot use AirTable if you are screen reader dependent. If you use a screen reader to augment low vision, you may be able to use some aspects of AirTable. Most of the buttons are not labeled, and there is no consistent use of headings. For example, in the Kanban view of a base, every element, including the tags, were all at heading level 1. The home screen includes two headers labeled "Home." The Project Tracker template has no labeled elements, and no way of knowing when you've reached the bottom of the page as a screen reader gets stuck in an endless loop around the two active elements on the page (these elements only said "open block view" and "expand extension options"). <br />
<br />
There is no usable alt text on images. Hidden spacer images are used and are not labeled, so there are many phantom "graphic" or "image" elements that appear on the page. Graphs are also not labeled and have no alternative text. It is unclear as a screen reader user how to get to the data contained within the graphs.<br />
<br />
=== Zoom, Text Size and Color Contrast ===<br />
<br />
AirTable becomes unusable at 300% zoom. At 200%, the side menu collapses into a hamburger menu that can't be used with a screen reader or keyboard, and any popups are cut off by the screen and can't be scrolled. <br />
<br />
Several areas of the interface uses very small text, and nearly every page had low-contrast errors coming up. The main text in some areas appears to be a medium gray instead of black. The main area where color blindness will inhibit use of the site were the charts and graphs sections. <br />
<br />
=== Contact Support ===<br />
<br />
AirTable no longer allows for questions to be emailed directly to support. You must go through the Help Menu in the AirTable interface and select "Message Support." Unfortunately, this action is impossible if you are screen reader dependent or only use the keyboard, as menu items cannot be navigated or selected through the keyboard. AirTable uses a chatbot to do a first-run of any questions, but our experiences with asking it questions is that it would give completely irrelevant information. You must use a mouse to select "talk to an agent;" again, making it impossible for a screen reader user to get help. They also direct users to their forums to ask questions, but a quick search (including the "General Information" links above) show that many questions remain unanswered, or are met with strangely aggressive resistance from other users.<br />
<br />
While it is understandable to ask individuals to create an account before reporting a problem to the support people, the lack of accessibility in these options limits the ability of some disabled users to ask for help or report accessibility issues. We are hoping our connection to the support group (developed through attending an AirTable training webinar) will allow us to report these issues and suggest an alternative or focused accessibility issue report form that is accessible. <br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=AirTable_Accessibility&diff=16550AirTable Accessibility2023-06-28T18:12:00Z<p>Dkrahmer: /* Known Accessibility Issues */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of AirTable. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
In general, AirTable is '''not accessible''' in the free version we tested. There are several barriers for anyone using Assistive Technologies, especially screen readers. It's a visually-heavy website that can be cognitively complex. We tested the backend of a free version to create a database, as well as some of the outputs of AirTable.<br />
<br />
== General Information ==<br />
<br />
* [https://support.airtable.com/docs/airtable-keyboard-shortcuts AirTable Keyboard Shortcuts]<br />
* [https://community.airtable.com/t5/other-questions/airtable-accessibility/td-p/130946 An interesting post on the community forum] about accessibility issues from 2020, featuring Michael Cyr from EDUCAUSE ITAccess group. <br />
* [https://community.airtable.com/t5/product-ideas/make-share-views-and-forms-accessible-to-aa-wcag-standards/idi-p/26542 Another forum post] from 2021 about accessibility issues in sharing and form formats. <br />
* [https://community.airtable.com/t5/product-ideas/accessibility-improvements-form/idi-p/120393 A forum post] that suggestions JotForm can be integrated to deal with some accessibility issues. <br />
* [https://wiki.fluidproject.org/display/fluid/Exploration+of+Airtable+for+use+with+Legal+Capacity+Inclusion+Lens A wiki post] outlining several issues that came up in testing AirTable in January 2022. <br />
* [https://www.businesshub.london/accessibility/ Businesshub is a website that uses AirTable,] but notes that it's not accessible to screen readers.<br />
* [https://gist.github.com/jlengstorf/a5a3a57b7b8475d2d00e3e58fc4d9eef Github post with markup changes] to improve accessibility.<br />
<br />
== Known Accessibility Issues ==<br />
<br />
=== Keyboard Control ===<br />
<br />
You cannot use a keyboard only to navigate the website. Several of the menus require the use of a mouse to activate options. The keyboard shortcuts page is inaccessible, and the keyboard shortcuts aren't usable if you depend on a screen reader. <br />
<br />
=== Screen Reader ===<br />
<br />
You cannot use AirTable if you are screen reader dependent. If you use a screen reader to augment low vision, you may be able to use some aspects of AirTable. Most of the buttons are not labeled, and there is no consistent use of headings. For example, in the Kanban view of a base, every element, including the tags, were all at heading level 1. The home screen includes two headers labeled "Home." The Project Tracker template has no labeled elements, and no way of knowing when you've reached the bottom of the page as a screen reader gets stuck in an endless loop around the two active elements on the page (these elements only said "open block view" and "expand extension options"). <br />
<br />
There is no usable alt text on images. Hidden spacer images are used and are not labeled, so there are many phantom "graphic" or "image" elements that appear on the page. Graphs are also not labeled and have no alternative text. It is unclear as a screen reader user how to get to the data contained within the graphs.<br />
<br />
=== Zoom Features ===<br />
<br />
AirTable becomes unusable at 300% zoom. <br />
<br />
=== Contact Support ===<br />
<br />
AirTable no longer allows for questions to be emailed directly to support. You must go through the Help Menu in the AirTable interface and select "Message Support." Unfortunately, this action is impossible if you are screen reader dependent or only use the keyboard, as menu items cannot be navigated or selected through the keyboard. AirTable uses a chatbot to do a first-run of any questions, but our experiences with asking it questions is that it would give completely irrelevant information. You must use a mouse to select "talk to an agent;" again, making it impossible for a screen reader user to get help. They also direct users to their forums to ask questions, but a quick search (including the links above) show that many questions remain unanswered, or are met with strangely aggressive resistance from other users. <br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=AirTable_Accessibility&diff=16549AirTable Accessibility2023-06-27T19:07:14Z<p>Dkrahmer: /* General Information */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of AirTable. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
In general, AirTable is '''not accessible''' in the free version we tested. There are several barriers for anyone using Assistive Technologies, especially screen readers. It's a visually-heavy website that can be cognitively complex. We tested the backend of a free version to create a database, as well as some of the outputs of AirTable.<br />
<br />
== General Information ==<br />
<br />
* [https://support.airtable.com/docs/airtable-keyboard-shortcuts AirTable Keyboard Shortcuts]<br />
* [https://community.airtable.com/t5/other-questions/airtable-accessibility/td-p/130946 An interesting post on the community forum] about accessibility issues from 2020, featuring Michael Cyr from EDUCAUSE ITAccess group. <br />
* [https://community.airtable.com/t5/product-ideas/make-share-views-and-forms-accessible-to-aa-wcag-standards/idi-p/26542 Another forum post] from 2021 about accessibility issues in sharing and form formats. <br />
* [https://community.airtable.com/t5/product-ideas/accessibility-improvements-form/idi-p/120393 A forum post] that suggestions JotForm can be integrated to deal with some accessibility issues. <br />
* [https://wiki.fluidproject.org/display/fluid/Exploration+of+Airtable+for+use+with+Legal+Capacity+Inclusion+Lens A wiki post] outlining several issues that came up in testing AirTable in January 2022. <br />
* [https://www.businesshub.london/accessibility/ Businesshub is a website that uses AirTable,] but notes that it's not accessible to screen readers.<br />
* [https://gist.github.com/jlengstorf/a5a3a57b7b8475d2d00e3e58fc4d9eef Github post with markup changes] to improve accessibility.<br />
<br />
== Known Accessibility Issues ==<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=AirTable_Accessibility&diff=16548AirTable Accessibility2023-06-27T19:05:24Z<p>Dkrahmer: /* General Information */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of AirTable. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
In general, AirTable is '''not accessible''' in the free version we tested. There are several barriers for anyone using Assistive Technologies, especially screen readers. It's a visually-heavy website that can be cognitively complex. We tested the backend of a free version to create a database, as well as some of the outputs of AirTable.<br />
<br />
== General Information ==<br />
<br />
* [https://support.airtable.com/docs/airtable-keyboard-shortcuts AirTable Keyboard Shortcuts]<br />
* [https://community.airtable.com/t5/other-questions/airtable-accessibility/td-p/130946 An interesting post on the community forum] about accessibility issues from 2020, featuring Michael Cyr from EDUCAUSE ITAccess group. <br />
* [https://community.airtable.com/t5/product-ideas/make-share-views-and-forms-accessible-to-aa-wcag-standards/idi-p/26542 Another forum post] from 2021 about accessibility issues in sharing and form formats. <br />
* [https://community.airtable.com/t5/product-ideas/accessibility-improvements-form/idi-p/120393 A forum post] that suggestions JotForm can be integrated to deal with some accessibility issues. <br />
* [https://wiki.fluidproject.org/display/fluid/Exploration+of+Airtable+for+use+with+Legal+Capacity+Inclusion+Lens A wiki post] outlining several issues that came up in testing AirTable in January 2022. <br />
* [https://www.businesshub.london/accessibility/ Businesshub is a website that uses AirTable,] but notes that it's not accessible to screen readers.<br />
<br />
== Known Accessibility Issues ==<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=AirTable_Accessibility&diff=16547AirTable Accessibility2023-06-27T18:38:17Z<p>Dkrahmer: /* Accessibility Overview */</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of AirTable. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
In general, AirTable is '''not accessible''' in the free version we tested. There are several barriers for anyone using Assistive Technologies, especially screen readers. It's a visually-heavy website that can be cognitively complex. We tested the backend of a free version to create a database, as well as some of the outputs of AirTable.<br />
<br />
== General Information ==<br />
<br />
* [https://support.airtable.com/docs/airtable-keyboard-shortcuts AirTable Keyboard Shortcuts]<br />
* [https://community.airtable.com/t5/other-questions/airtable-accessibility/td-p/130946 An interesting post on the community forum] about accessibility issues from 2020, featuring Michael Cyr from EDUCAUSE ITAccess group. <br />
* <br />
<br />
== Known Accessibility Issues ==<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=AirTable_Accessibility&diff=16546AirTable Accessibility2023-06-27T18:32:50Z<p>Dkrahmer: Created page with "This page gathers the IT Subcommittee's resources and reviews of the accessibility of AirTable. This page will be updated as new information is available or further reviews are conducted. == Accessibility Overview == In general, AirTable is '''not accessible''' in the free version we tested. There are several barriers for anyone using Assistive Technologies, especially screen readers. It's a visually-heavy website that can be cognitively complex. We tested the backend..."</p>
<hr />
<div>This page gathers the IT Subcommittee's resources and reviews of the accessibility of AirTable. This page will be updated as new information is available or further reviews are conducted.<br />
<br />
== Accessibility Overview ==<br />
<br />
In general, AirTable is '''not accessible''' in the free version we tested. There are several barriers for anyone using Assistive Technologies, especially screen readers. It's a visually-heavy website that can be cognitively complex. We tested the backend of a free version, as well as some of the outputs of AirTable.<br />
<br />
== General Information ==<br />
<br />
* [https://support.airtable.com/docs/airtable-keyboard-shortcuts AirTable Keyboard Shortcuts]<br />
* [https://community.airtable.com/t5/other-questions/airtable-accessibility/td-p/130946 An interesting post on the community forum] about accessibility issues from 2020, featuring Michael Cyr from EDUCAUSE ITAccess group. <br />
* <br />
<br />
== Known Accessibility Issues ==<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16545Accessibility Auditing Shortlist2023-06-27T18:13:38Z<p>Dkrahmer: /* First Steps */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# If the vendor or website has an internal search mechanism (i.e. search box to search the site), test to see if it actually works. You can compare it to a similar search in Google using site searching (add site:website.com to your search string in Google, replacing the address with the top level domain of the site you want to search). <br />
## Rationale: A working internal search can save a user a lot of time and energy if it works. Optimally, you could use the internal search to find the keyboard shortcuts, vpat, or other accessibility information. If the internal search doesn't work, then it's useless to help anyone.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
# Test out basic keyboard-only access to the website.<br />
## Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes? <br />
### Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit [https://nomouse.org/ Take the #NoMouse Challenge] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics].<br />
## Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
### Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.<br />
## Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?<br />
### Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.<br />
## Does the vendor include a list of keyboard shortcuts? Record that information. <br />
## How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?<br />
# Does the website or software require the user to drag-and-drop to do something, without having an alternative?<br />
## Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
# Does the website use color alone to denote meaning? <br />
## Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
## Does being color blind in some way affect a user’s ability to fully use the site? Is there a difference in color between a visited link and a non-visited link?<br />
### Rationale: Using color alone can affect how users who are color blind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
# Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
## Is any information cut off or made incomprehensible or inaccessible?<br />
## Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All?<br />
### Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%.<br />
# Are the links on the website accessible?<br />
## Are the links a different color from the regular text? Are they underlined?<br />
### Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. [https://webaim.org/resources/contrastchecker/ Use the WebAIM Contrast Checker].<br />
## Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?<br />
### Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web.<br />
# Do all videos use subtitles or closed captioning? Are transcripts available for audio content (and do they have timecodes)? Are they automatically generated? Are they accurate? <br />
## Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually.<br />
# Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information.<br />
# Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
## Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Certain users will not have access to the information conveyed in complex images designed to convey information (e.g. screenshots of workflows) if they do not have associated descriptive captions or text.Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
<br />
===Next Steps===<br />
These tasks are more easily accomplished by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually. Please consult the full [https://wiki.diglib.org/Accessibility_Auditing_Resources Accessibility Auditing Resources] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing. These steps have fewer explanatory text because they are geared towards more experienced testers.<br />
<br />
# Perform whatever tests you typically perform while doing an accessibility audit and share your results on the working document, such as using the steps above or an advanced accessibility checker like [https://www.deque.com/axe/ AXE] ([https://www.deque.com/axe/devtools/ browser extension]). Record the results.<br />
# If you have knowledge about VPATs, please share your insights about the VPAT for the service if it exists.<br />
# Does navigation facilitate ease of use?<br />
## Consistent layout and design<br />
## No broken links, or there is a way to report broken links<br />
## Page content hierarchy follows heading guidelines<br />
## Underlined text is avoided unless used for URL navigation<br />
## Is the reading/document order logical and/or natural?<br />
## Is there a “skip to main content” link? Does it go to the most logical “main content?”<br />
# Do images have useful alt text, depending on the context? Do they use a null alt text (alt=””) for decorative images? Refer to the [https://www.w3.org/WAI/tutorials/images/tips/ W3 Image Tutorial Tips and Tricks] for guidance on constructing alt text.<br />
# Does the site properly use [https://accessibility.oit.ncsu.edu/using-aria-landmarks-a-demonstration/ ARIA landmarks]?<br />
# Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
## What barriers are encountered?<br />
## Are any pop-ups or form fields invisible to the screen reader? Do any pop-ups or menus not work with a keyboard?<br />
## Can a user navigate and use the site without using sight?<br />
# Does the page use proper HTML formatting? Ex. Uses H2 instead of bold or a different color of text to create a heading. <br />
# How does the website look or perform on a mobile device browser? Test both Android and iOS.<br />
# Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups?<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. Disabled users are the experts at using their own Assistive Technologies, and can give practical work-arounds that may be missed by other users (especially when they are new to the AT or software, or are stressed out because something isn’t working). <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback.<br />
If you are doing testing at your own organization, it is important to compensate disabled users for their time and expertise. Even if the person is an employee at your organization, if it is not part of their regular duties, they should receive extra compensation.<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
** This wiki uses a basic instance of MediaWiki.<br />
* [https://www.a11yproject.com/ A11y Project]<br />
** This website has several tutorials on accessibility, so you can use it to practice testing while also learning more about accessibility. <br />
* [https://www.w3.org/WAI/demos/bad/before/home.html W3 Example of an Inaccessible Webpage] <br />
** This example website is purposely inaccessible, and includes annotations explaining things, as well as the accessible version<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=IT_and_Development&diff=16544IT and Development2023-06-27T18:07:20Z<p>Dkrahmer: /* Accessibility Audits */</p>
<hr />
<div>The IT and Development subgroup will focus on specific software, hardware, and development practices associated with information organizations. Once a list of technologies associated with specific areas is compiled, they will begin addressing the accessibility concerns of specific entries. We adhere to the same mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group]. <br />
<br />
==Monthly Meetings==<br />
<br />
For 2023, the DLF DAWG-IT subgroup is moving on from testing the software used by our parent organization and instead will focus on assessing the accessibility of other GLAM technologies. Our initial focus was on [[Zotero Accessibility|Zotero]]. We're collaborating with a group of librarians in Canada who are already pushing for more accessibility within Zotero.<br />
<br />
Then we will move on to [https://docs.google.com/document/d/1SoJnsOdUPzE-m7tEbx11uFQ-cxO69YkYLHvXnElM6lA/edit?usp=sharing Online conference platforms]. We've collected notes over the past two years about accessibility issues, and will figure out how to place it into a more useful document for the future. <br />
<br />
Meetings will be held on the final Monday of the month, at 11:15am Eastern/3:15pm GMT. ([https://www.thetimezoneconverter.com/ Timezone converter]) Check the [https://docs.google.com/document/d/1yXEgjUEdUfu5ORBOAOLvdBNZqFHpQOxTULxcvy4EfCc/edit 2023 running agenda] for more information, including links to register for the meetings.<br />
<br />
== Completed Projects ==<br />
* [[Accessible Documentation]]<br />
* [[Accessibility Auditing Resources]]<br />
* [[Accessibility Auditing Shortlist]]<br />
* [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit?usp=sharing Accessibility Auditing Template] Google Doc. Make a copy to start your own evaluation.<br />
<br />
== Accessibility Audits ==<br />
In 2021, the DAWG-IT subgroup focused on accessibility testing of the software typically used for DAWG meetings and events. For 2022, we are focusing on broader GLAM software. These are our completed audits:<br />
<br />
* [[Zoom Accessibility]]<br />
* [[Doodle.com Accessibility]]<br />
* [[Google Forms Accessibility]]<br />
* [[Otter.ai Accessibility]]<br />
* [[Google Docs Accessibility]]<br />
* [[Google Slides Accessibility]]<br />
* [[Zotero Accessibility]]<br />
* [[Online Conference Platforms Accessibility]]<br />
* [[ArchivesSpace Accessibility]]<br />
* [[AirTable Accessibility]]<br />
<br />
== Group Organizers ==<br />
* Debbie Krahmer dkrahmer AT cornell.edu<br />
<br />
== Members ==<br />
* Ima Odouk<br />
* Elliot Stevens<br />
* Wendy Robertson<br />
* Kristen Heldmann<br />
* Gabe Galson<br />
* Hannah Sistrunk<br />
* Rita Johnston<br />
* Penniphurr Stevenson<br />
* Eudora Struble<br />
* Deseree Stukes<br />
* Jonathan Milam<br />
<br />
== Future Technologies to Research ==<br />
Everyone is welcome to participate, regardless of your own personal level of skill with accessibility auditing. We've compiled an [[Accessibility Auditing Shortlist]] that anyone can use to contribute to the knowledge base. The ultimate goal for all of these audits is to make the information freely available to anyone. Google docs is currently used for the initial working document before moving information to the wiki. Contact the Organizers for information on how to join the community and get wiki editing access.<br />
<br />
* [https://docs.google.com/document/d/1gAS04mUZSM7g1VBcF5kfry0uuHqvMQc21nXso20h5Pg/edit?usp=sharing Google Sheets]<br />
* [https://docs.google.com/document/d/1vGJey7_KQdM0lLYAdt9W8DkiuWaJXKF-BuvDulsUMbA/edit?usp=sharing Slack]<br />
* OJS, open journal systems<br />
* Institutional Repositories (bepress, DSpace, etc.)<br />
* DAMs (Contentdm, Islandora, etc.)<br />
* Library Systems<br />
* Virtual Tours<br />
* Digital Scholarship (Research data, tools, visualizations)<br />
* Databases and Vendors<br />
* Virtual Reality (3D technologies, including Makerspace equipment)<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16508Accessibility Auditing Shortlist2023-05-22T18:49:12Z<p>Dkrahmer: /* Websites you can practice on */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
# Test out basic keyboard-only access to the website.<br />
## Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes? <br />
### Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit [https://nomouse.org/ Take the #NoMouse Challenge] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics].<br />
## Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
### Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.<br />
## Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?<br />
### Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.<br />
## Does the vendor include a list of keyboard shortcuts? Record that information. <br />
## How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?<br />
# Does the website or software require the user to drag-and-drop to do something, without having an alternative?<br />
## Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
# Does the website use color alone to denote meaning? <br />
## Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
## Does being color blind in some way affect a user’s ability to fully use the site? Is there a difference in color between a visited link and a non-visited link?<br />
### Rationale: Using color alone can affect how users who are color blind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
# Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
## Is any information cut off or made incomprehensible or inaccessible?<br />
## Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All?<br />
### Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%.<br />
# Are the links on the website accessible?<br />
## Are the links a different color from the regular text? Are they underlined?<br />
### Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. [https://webaim.org/resources/contrastchecker/ Use the WebAIM Contrast Checker].<br />
## Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?<br />
### Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web.<br />
# Do all videos use subtitles or closed captioning? Are transcripts available for audio content (and do they have timecodes)? Are they automatically generated? Are they accurate? <br />
## Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually.<br />
# Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information.<br />
# Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
## Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Certain users will not have access to the information conveyed in complex images designed to convey information (e.g. screenshots of workflows) if they do not have associated descriptive captions or text.Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
<br />
===Next Steps===<br />
These tasks are more easily accomplished by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually. Please consult the full [https://wiki.diglib.org/Accessibility_Auditing_Resources Accessibility Auditing Resources] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing. These steps have fewer explanatory text because they are geared towards more experienced testers.<br />
<br />
# Perform whatever tests you typically perform while doing an accessibility audit and share your results on the working document, such as using the steps above or an advanced accessibility checker like [https://www.deque.com/axe/ AXE] ([https://www.deque.com/axe/devtools/ browser extension]). Record the results.<br />
# If you have knowledge about VPATs, please share your insights about the VPAT for the service if it exists.<br />
# Does navigation facilitate ease of use?<br />
## Consistent layout and design<br />
## No broken links, or there is a way to report broken links<br />
## Page content hierarchy follows heading guidelines<br />
## Underlined text is avoided unless used for URL navigation<br />
## Is the reading/document order logical and/or natural?<br />
## Is there a “skip to main content” link? Does it go to the most logical “main content?”<br />
# Do images have useful alt text, depending on the context? Do they use a null alt text (alt=””) for decorative images? Refer to the [https://www.w3.org/WAI/tutorials/images/tips/ W3 Image Tutorial Tips and Tricks] for guidance on constructing alt text.<br />
# Does the site properly use [https://accessibility.oit.ncsu.edu/using-aria-landmarks-a-demonstration/ ARIA landmarks]?<br />
# Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
## What barriers are encountered?<br />
## Are any pop-ups or form fields invisible to the screen reader? Do any pop-ups or menus not work with a keyboard?<br />
## Can a user navigate and use the site without using sight?<br />
# Does the page use proper HTML formatting? Ex. Uses H2 instead of bold or a different color of text to create a heading. <br />
# How does the website look or perform on a mobile device browser? Test both Android and iOS.<br />
# Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups?<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. Disabled users are the experts at using their own Assistive Technologies, and can give practical work-arounds that may be missed by other users (especially when they are new to the AT or software, or are stressed out because something isn’t working). <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback.<br />
If you are doing testing at your own organization, it is important to compensate disabled users for their time and expertise. Even if the person is an employee at your organization, if it is not part of their regular duties, they should receive extra compensation.<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
** This wiki uses a basic instance of MediaWiki.<br />
* [https://www.a11yproject.com/ A11y Project]<br />
** This website has several tutorials on accessibility, so you can use it to practice testing while also learning more about accessibility. <br />
* [https://www.w3.org/WAI/demos/bad/before/home.html W3 Example of an Inaccessible Webpage] <br />
** This example website is purposely inaccessible, and includes annotations explaining things, as well as the accessible version<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16507Accessibility Auditing Shortlist2023-05-22T18:48:12Z<p>Dkrahmer: /* Websites you can practice on */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
# Test out basic keyboard-only access to the website.<br />
## Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes? <br />
### Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit [https://nomouse.org/ Take the #NoMouse Challenge] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics].<br />
## Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
### Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.<br />
## Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?<br />
### Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.<br />
## Does the vendor include a list of keyboard shortcuts? Record that information. <br />
## How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?<br />
# Does the website or software require the user to drag-and-drop to do something, without having an alternative?<br />
## Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
# Does the website use color alone to denote meaning? <br />
## Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
## Does being color blind in some way affect a user’s ability to fully use the site? Is there a difference in color between a visited link and a non-visited link?<br />
### Rationale: Using color alone can affect how users who are color blind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
# Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
## Is any information cut off or made incomprehensible or inaccessible?<br />
## Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All?<br />
### Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%.<br />
# Are the links on the website accessible?<br />
## Are the links a different color from the regular text? Are they underlined?<br />
### Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. [https://webaim.org/resources/contrastchecker/ Use the WebAIM Contrast Checker].<br />
## Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?<br />
### Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web.<br />
# Do all videos use subtitles or closed captioning? Are transcripts available for audio content (and do they have timecodes)? Are they automatically generated? Are they accurate? <br />
## Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually.<br />
# Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information.<br />
# Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
## Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Certain users will not have access to the information conveyed in complex images designed to convey information (e.g. screenshots of workflows) if they do not have associated descriptive captions or text.Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
<br />
===Next Steps===<br />
These tasks are more easily accomplished by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually. Please consult the full [https://wiki.diglib.org/Accessibility_Auditing_Resources Accessibility Auditing Resources] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing. These steps have fewer explanatory text because they are geared towards more experienced testers.<br />
<br />
# Perform whatever tests you typically perform while doing an accessibility audit and share your results on the working document, such as using the steps above or an advanced accessibility checker like [https://www.deque.com/axe/ AXE] ([https://www.deque.com/axe/devtools/ browser extension]). Record the results.<br />
# If you have knowledge about VPATs, please share your insights about the VPAT for the service if it exists.<br />
# Does navigation facilitate ease of use?<br />
## Consistent layout and design<br />
## No broken links, or there is a way to report broken links<br />
## Page content hierarchy follows heading guidelines<br />
## Underlined text is avoided unless used for URL navigation<br />
## Is the reading/document order logical and/or natural?<br />
## Is there a “skip to main content” link? Does it go to the most logical “main content?”<br />
# Do images have useful alt text, depending on the context? Do they use a null alt text (alt=””) for decorative images? Refer to the [https://www.w3.org/WAI/tutorials/images/tips/ W3 Image Tutorial Tips and Tricks] for guidance on constructing alt text.<br />
# Does the site properly use [https://accessibility.oit.ncsu.edu/using-aria-landmarks-a-demonstration/ ARIA landmarks]?<br />
# Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
## What barriers are encountered?<br />
## Are any pop-ups or form fields invisible to the screen reader? Do any pop-ups or menus not work with a keyboard?<br />
## Can a user navigate and use the site without using sight?<br />
# Does the page use proper HTML formatting? Ex. Uses H2 instead of bold or a different color of text to create a heading. <br />
# How does the website look or perform on a mobile device browser? Test both Android and iOS.<br />
# Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups?<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. Disabled users are the experts at using their own Assistive Technologies, and can give practical work-arounds that may be missed by other users (especially when they are new to the AT or software, or are stressed out because something isn’t working). <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback.<br />
If you are doing testing at your own organization, it is important to compensate disabled users for their time and expertise. Even if the person is an employee at your organization, if it is not part of their regular duties, they should receive extra compensation.<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
** This wiki uses a basic instance of MediaWiki.<br />
* [https://www.a11yproject.com/ A11y Project]<br />
** This website has several tutorials on accessibility, so you can use it to practice testing while also learning more about accessibility. <br />
* W3 Example of an Inaccessible Webpage <br />
** This example website is purposely inaccessible, and includes annotations explaining things, as well as the accessible version<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16506Accessibility Auditing Shortlist2023-05-22T18:41:57Z<p>Dkrahmer: /* Assistive Technology User Testing */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
# Test out basic keyboard-only access to the website.<br />
## Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes? <br />
### Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit [https://nomouse.org/ Take the #NoMouse Challenge] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics].<br />
## Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
### Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.<br />
## Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?<br />
### Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.<br />
## Does the vendor include a list of keyboard shortcuts? Record that information. <br />
## How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?<br />
# Does the website or software require the user to drag-and-drop to do something, without having an alternative?<br />
## Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
# Does the website use color alone to denote meaning? <br />
## Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
## Does being color blind in some way affect a user’s ability to fully use the site? Is there a difference in color between a visited link and a non-visited link?<br />
### Rationale: Using color alone can affect how users who are color blind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
# Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
## Is any information cut off or made incomprehensible or inaccessible?<br />
## Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All?<br />
### Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%.<br />
# Are the links on the website accessible?<br />
## Are the links a different color from the regular text? Are they underlined?<br />
### Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. [https://webaim.org/resources/contrastchecker/ Use the WebAIM Contrast Checker].<br />
## Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?<br />
### Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web.<br />
# Do all videos use subtitles or closed captioning? Are transcripts available for audio content (and do they have timecodes)? Are they automatically generated? Are they accurate? <br />
## Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually.<br />
# Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information.<br />
# Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
## Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Certain users will not have access to the information conveyed in complex images designed to convey information (e.g. screenshots of workflows) if they do not have associated descriptive captions or text.Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
<br />
===Next Steps===<br />
These tasks are more easily accomplished by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually. Please consult the full [https://wiki.diglib.org/Accessibility_Auditing_Resources Accessibility Auditing Resources] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing. These steps have fewer explanatory text because they are geared towards more experienced testers.<br />
<br />
# Perform whatever tests you typically perform while doing an accessibility audit and share your results on the working document, such as using the steps above or an advanced accessibility checker like [https://www.deque.com/axe/ AXE] ([https://www.deque.com/axe/devtools/ browser extension]). Record the results.<br />
# If you have knowledge about VPATs, please share your insights about the VPAT for the service if it exists.<br />
# Does navigation facilitate ease of use?<br />
## Consistent layout and design<br />
## No broken links, or there is a way to report broken links<br />
## Page content hierarchy follows heading guidelines<br />
## Underlined text is avoided unless used for URL navigation<br />
## Is the reading/document order logical and/or natural?<br />
## Is there a “skip to main content” link? Does it go to the most logical “main content?”<br />
# Do images have useful alt text, depending on the context? Do they use a null alt text (alt=””) for decorative images? Refer to the [https://www.w3.org/WAI/tutorials/images/tips/ W3 Image Tutorial Tips and Tricks] for guidance on constructing alt text.<br />
# Does the site properly use [https://accessibility.oit.ncsu.edu/using-aria-landmarks-a-demonstration/ ARIA landmarks]?<br />
# Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
## What barriers are encountered?<br />
## Are any pop-ups or form fields invisible to the screen reader? Do any pop-ups or menus not work with a keyboard?<br />
## Can a user navigate and use the site without using sight?<br />
# Does the page use proper HTML formatting? Ex. Uses H2 instead of bold or a different color of text to create a heading. <br />
# How does the website look or perform on a mobile device browser? Test both Android and iOS.<br />
# Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups?<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. Disabled users are the experts at using their own Assistive Technologies, and can give practical work-arounds that may be missed by other users (especially when they are new to the AT or software, or are stressed out because something isn’t working). <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback.<br />
If you are doing testing at your own organization, it is important to compensate disabled users for their time and expertise. Even if the person is an employee at your organization, if it is not part of their regular duties, they should receive extra compensation.<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://libguides.colgate.edu/remoteprimarysources Colgate University LibGuide with Appointlet]<br />
**Navigate the site with only a keyboard. <br />
**Is it possible to book an appointment with Sarah only using a keyboard? What about Xena?<br />
**Can a user book an appointment using a screen reader? Can you cancel it? <br />
***Rationale: This page has an inaccessible widget for booking an appointment with Xena. It can’t be activated without the mouse, and the form elements are unlabeled, so a screen reader user wouldn’t know what information to put into the form. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
* [https://www.a11yproject.com/ A11y Project]<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16505Accessibility Auditing Shortlist2023-05-22T18:41:07Z<p>Dkrahmer: /* Next Steps */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
# Test out basic keyboard-only access to the website.<br />
## Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes? <br />
### Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit [https://nomouse.org/ Take the #NoMouse Challenge] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics].<br />
## Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
### Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.<br />
## Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?<br />
### Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.<br />
## Does the vendor include a list of keyboard shortcuts? Record that information. <br />
## How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?<br />
# Does the website or software require the user to drag-and-drop to do something, without having an alternative?<br />
## Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
# Does the website use color alone to denote meaning? <br />
## Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
## Does being color blind in some way affect a user’s ability to fully use the site? Is there a difference in color between a visited link and a non-visited link?<br />
### Rationale: Using color alone can affect how users who are color blind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
# Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
## Is any information cut off or made incomprehensible or inaccessible?<br />
## Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All?<br />
### Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%.<br />
# Are the links on the website accessible?<br />
## Are the links a different color from the regular text? Are they underlined?<br />
### Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. [https://webaim.org/resources/contrastchecker/ Use the WebAIM Contrast Checker].<br />
## Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?<br />
### Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web.<br />
# Do all videos use subtitles or closed captioning? Are transcripts available for audio content (and do they have timecodes)? Are they automatically generated? Are they accurate? <br />
## Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually.<br />
# Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information.<br />
# Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
## Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Certain users will not have access to the information conveyed in complex images designed to convey information (e.g. screenshots of workflows) if they do not have associated descriptive captions or text.Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
<br />
===Next Steps===<br />
These tasks are more easily accomplished by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually. Please consult the full [https://wiki.diglib.org/Accessibility_Auditing_Resources Accessibility Auditing Resources] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing. These steps have fewer explanatory text because they are geared towards more experienced testers.<br />
<br />
# Perform whatever tests you typically perform while doing an accessibility audit and share your results on the working document, such as using the steps above or an advanced accessibility checker like [https://www.deque.com/axe/ AXE] ([https://www.deque.com/axe/devtools/ browser extension]). Record the results.<br />
# If you have knowledge about VPATs, please share your insights about the VPAT for the service if it exists.<br />
# Does navigation facilitate ease of use?<br />
## Consistent layout and design<br />
## No broken links, or there is a way to report broken links<br />
## Page content hierarchy follows heading guidelines<br />
## Underlined text is avoided unless used for URL navigation<br />
## Is the reading/document order logical and/or natural?<br />
## Is there a “skip to main content” link? Does it go to the most logical “main content?”<br />
# Do images have useful alt text, depending on the context? Do they use a null alt text (alt=””) for decorative images? Refer to the [https://www.w3.org/WAI/tutorials/images/tips/ W3 Image Tutorial Tips and Tricks] for guidance on constructing alt text.<br />
# Does the site properly use [https://accessibility.oit.ncsu.edu/using-aria-landmarks-a-demonstration/ ARIA landmarks]?<br />
# Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
## What barriers are encountered?<br />
## Are any pop-ups or form fields invisible to the screen reader? Do any pop-ups or menus not work with a keyboard?<br />
## Can a user navigate and use the site without using sight?<br />
# Does the page use proper HTML formatting? Ex. Uses H2 instead of bold or a different color of text to create a heading. <br />
# How does the website look or perform on a mobile device browser? Test both Android and iOS.<br />
# Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups?<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback. <br />
<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://libguides.colgate.edu/remoteprimarysources Colgate University LibGuide with Appointlet]<br />
**Navigate the site with only a keyboard. <br />
**Is it possible to book an appointment with Sarah only using a keyboard? What about Xena?<br />
**Can a user book an appointment using a screen reader? Can you cancel it? <br />
***Rationale: This page has an inaccessible widget for booking an appointment with Xena. It can’t be activated without the mouse, and the form elements are unlabeled, so a screen reader user wouldn’t know what information to put into the form. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
* [https://www.a11yproject.com/ A11y Project]<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16504Accessibility Auditing Shortlist2023-05-22T18:40:05Z<p>Dkrahmer: /* Next Steps */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
# Test out basic keyboard-only access to the website.<br />
## Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes? <br />
### Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit [https://nomouse.org/ Take the #NoMouse Challenge] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics].<br />
## Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
### Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.<br />
## Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?<br />
### Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.<br />
## Does the vendor include a list of keyboard shortcuts? Record that information. <br />
## How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?<br />
# Does the website or software require the user to drag-and-drop to do something, without having an alternative?<br />
## Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
# Does the website use color alone to denote meaning? <br />
## Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
## Does being color blind in some way affect a user’s ability to fully use the site? Is there a difference in color between a visited link and a non-visited link?<br />
### Rationale: Using color alone can affect how users who are color blind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
# Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
## Is any information cut off or made incomprehensible or inaccessible?<br />
## Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All?<br />
### Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%.<br />
# Are the links on the website accessible?<br />
## Are the links a different color from the regular text? Are they underlined?<br />
### Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. [https://webaim.org/resources/contrastchecker/ Use the WebAIM Contrast Checker].<br />
## Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?<br />
### Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web.<br />
# Do all videos use subtitles or closed captioning? Are transcripts available for audio content (and do they have timecodes)? Are they automatically generated? Are they accurate? <br />
## Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually.<br />
# Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information.<br />
# Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
## Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Certain users will not have access to the information conveyed in complex images designed to convey information (e.g. screenshots of workflows) if they do not have associated descriptive captions or text.Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
<br />
===Next Steps===<br />
These tasks are more easily accomplished by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually. Please consult the full [https://wiki.diglib.org/Accessibility_Auditing_Resources Accessibility Auditing Resources] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing. These steps have fewer explanatory text because they are geared towards more experienced testers.<br />
<br />
# Perform whatever tests you typically perform while doing an accessibility audit and share your results on the working document, such as using the steps above or an advanced accessibility checker like [https://www.deque.com/axe/ AXE] ([https://www.deque.com/axe/devtools/ browser extension]). Record the results.<br />
# If you have knowledge about VPATs, please share your insights about the VPAT for the service if it exists.<br />
# Does navigation facilitate ease of use?<br />
## Consistent layout and design<br />
## No broken links, or there is a way to report broken links<br />
## Page content hierarchy follows heading guidelines<br />
## Underlined text is avoided unless used for URL navigation<br />
## Is the reading/document order logical and/or natural?<br />
## Is there a “skip to main content” link? Does it go to the most logical “main content?”<br />
# Do images have useful alt text, depending on the context? Do they use a null alt text (alt=””) for decorative images? Refer to the [https://www.w3.org/WAI/tutorials/images/tips/ W3 Image Tutorial Tips and Tricks] for guidance on constructing alt text.<br />
# Does the site properly use [https://accessibility.oit.ncsu.edu/using-aria-landmarks-a-demonstration/ ARIA landmarks]?<br />
# Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
What barriers are encountered?<br />
## Are any pop-ups or form fields invisible to the screen reader? Do any pop-ups or menus not work with a keyboard?<br />
## Can a user navigate and use the site without using sight?<br />
# Does the page use proper HTML formatting? Ex. Uses H2 instead of bold or a different color of text to create a heading. <br />
# How does the website look or perform on a mobile device browser? Test both Android and iOS.<br />
# Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups?<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback. <br />
<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://libguides.colgate.edu/remoteprimarysources Colgate University LibGuide with Appointlet]<br />
**Navigate the site with only a keyboard. <br />
**Is it possible to book an appointment with Sarah only using a keyboard? What about Xena?<br />
**Can a user book an appointment using a screen reader? Can you cancel it? <br />
***Rationale: This page has an inaccessible widget for booking an appointment with Xena. It can’t be activated without the mouse, and the form elements are unlabeled, so a screen reader user wouldn’t know what information to put into the form. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
* [https://www.a11yproject.com/ A11y Project]<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16503Accessibility Auditing Shortlist2023-05-22T18:36:58Z<p>Dkrahmer: /* Next Steps */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
# Test out basic keyboard-only access to the website.<br />
## Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes? <br />
### Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit [https://nomouse.org/ Take the #NoMouse Challenge] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics].<br />
## Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
### Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.<br />
## Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?<br />
### Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.<br />
## Does the vendor include a list of keyboard shortcuts? Record that information. <br />
## How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?<br />
# Does the website or software require the user to drag-and-drop to do something, without having an alternative?<br />
## Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
# Does the website use color alone to denote meaning? <br />
## Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
## Does being color blind in some way affect a user’s ability to fully use the site? Is there a difference in color between a visited link and a non-visited link?<br />
### Rationale: Using color alone can affect how users who are color blind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
# Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
## Is any information cut off or made incomprehensible or inaccessible?<br />
## Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All?<br />
### Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%.<br />
# Are the links on the website accessible?<br />
## Are the links a different color from the regular text? Are they underlined?<br />
### Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. [https://webaim.org/resources/contrastchecker/ Use the WebAIM Contrast Checker].<br />
## Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?<br />
### Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web.<br />
# Do all videos use subtitles or closed captioning? Are transcripts available for audio content (and do they have timecodes)? Are they automatically generated? Are they accurate? <br />
## Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually.<br />
# Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information.<br />
# Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
## Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Certain users will not have access to the information conveyed in complex images designed to convey information (e.g. screenshots of workflows) if they do not have associated descriptive captions or text.Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
<br />
===Next Steps===<br />
These tasks are more easily accomplished by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually. Please consult the full [https://wiki.diglib.org/Accessibility_Auditing_Resources Accessibility Auditing Resources] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing. These steps have fewer explanatory text because they are geared towards more experienced testers.<br />
<br />
# Perform whatever tests you typically perform while doing an accessibility audit and share your results on the working document, such as using the steps above or an advanced accessibility checker like [https://www.deque.com/axe/ AXE] ([https://www.deque.com/axe/devtools/ browser extension]). Record the results.<br />
# If you have knowledge about VPATs, please share your insights about the VPAT for the service if it exists.<br />
# Does navigation facilitate ease of use?<br />
## Consistent layout and design<br />
## No broken links, or there is a way to report broken links<br />
## Page content hierarchy follows heading guidelines<br />
## Underlined text is avoided unless used for URL navigation<br />
## Is the reading/document order logical and/or natural?<br />
## Is there a “skip to main content” link? Does it go to the most logical “main content?”<br />
# Do images have useful alt text, depending on the context? Do they use a null alt text (alt=””) for decorative images? Refer to the [https://www.w3.org/WAI/tutorials/images/tips/ W3 Image Tutorial Tips and Tricks] for guidance on constructing alt text.<br />
<br />
<br />
<br />
<br />
<br />
#Perform whatever tests you typically perform while doing an accessibility audit, and share your results on the working document. If you have knowledge about VPATs, please share your insights to the VPAT for the service if it exists. <br />
#Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
##Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
#Test out the keyboard accessibility of the software. <br />
##Does the vendor include a list of keyboard shortcuts? Are the shortcuts significantly different from what’s typically used? <br />
##How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated? <br />
##Can a user see the focus state of where the focus is on the webpage? <br />
#Does navigation facilitate ease of use?<br />
##Consistent layout and design; design elements increase predictability<br />
##No broken links, or there is a way to report broken links<br />
##Page content hierarchy follows heading guidelines <br />
##Underlined text is avoided unless used for URL navigation<br />
#Do images have alt text? Is the alt text appropriate for the website or software? Do they use a null alt text for decorative images? <br />
#Use [https://www.deque.com/axe/ AXE] ([https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US axe chrome extension]) or another advanced accessibility checker to test the webpages for more specific errors. Record the results. <br />
#Is there a “skip to main content” link?<br />
#Does the site properly use aria landmarks? <br />
#Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
##What barriers are encountered? <br />
##Are any pop-ups or form fields invisible to the screen reader? <br />
##Can a user navigate and use the site without using sight?<br />
##Can a screen reader tell the difference between colored elements?<br />
###Rationale: An example of using color alone to denote meaning is when headings or subheadings are not actually using proper HTML code to mark up the page, a screen reader for example would not be able to recognize that heading or subheading as such, and would read those headings as paragraph text. <br />
#Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups? <br />
#How does the website look or perform on a mobile device? Is there an app? Is it accessible? Test both Android and iOS.<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback. <br />
<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://libguides.colgate.edu/remoteprimarysources Colgate University LibGuide with Appointlet]<br />
**Navigate the site with only a keyboard. <br />
**Is it possible to book an appointment with Sarah only using a keyboard? What about Xena?<br />
**Can a user book an appointment using a screen reader? Can you cancel it? <br />
***Rationale: This page has an inaccessible widget for booking an appointment with Xena. It can’t be activated without the mouse, and the form elements are unlabeled, so a screen reader user wouldn’t know what information to put into the form. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
* [https://www.a11yproject.com/ A11y Project]<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16502Accessibility Auditing Shortlist2023-05-22T18:30:25Z<p>Dkrahmer: /* First Steps */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
# Test out basic keyboard-only access to the website.<br />
## Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes? <br />
### Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit [https://nomouse.org/ Take the #NoMouse Challenge] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics].<br />
## Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
### Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.<br />
## Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?<br />
### Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.<br />
## Does the vendor include a list of keyboard shortcuts? Record that information. <br />
## How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?<br />
# Does the website or software require the user to drag-and-drop to do something, without having an alternative?<br />
## Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
# Does the website use color alone to denote meaning? <br />
## Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
## Does being color blind in some way affect a user’s ability to fully use the site? Is there a difference in color between a visited link and a non-visited link?<br />
### Rationale: Using color alone can affect how users who are color blind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
# Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
## Is any information cut off or made incomprehensible or inaccessible?<br />
## Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All?<br />
### Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%.<br />
# Are the links on the website accessible?<br />
## Are the links a different color from the regular text? Are they underlined?<br />
### Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. [https://webaim.org/resources/contrastchecker/ Use the WebAIM Contrast Checker].<br />
## Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?<br />
### Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web.<br />
# Do all videos use subtitles or closed captioning? Are transcripts available for audio content (and do they have timecodes)? Are they automatically generated? Are they accurate? <br />
## Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually.<br />
# Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information.<br />
# Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
## Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Certain users will not have access to the information conveyed in complex images designed to convey information (e.g. screenshots of workflows) if they do not have associated descriptive captions or text.Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
<br />
===Next Steps===<br />
These tasks should be completed by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually, by someone who has some experience. As you feel more comfortable with the techniques you are learning, you can continue to expand our collection of information about a service. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing.<br />
<br />
#Perform whatever tests you typically perform while doing an accessibility audit, and share your results on the working document. If you have knowledge about VPATs, please share your insights to the VPAT for the service if it exists. <br />
#Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
##Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
#Test out the keyboard accessibility of the software. <br />
##Does the vendor include a list of keyboard shortcuts? Are the shortcuts significantly different from what’s typically used? <br />
##How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated? <br />
##Can a user see the focus state of where the focus is on the webpage? <br />
#Does navigation facilitate ease of use?<br />
##Consistent layout and design; design elements increase predictability<br />
##No broken links, or there is a way to report broken links<br />
##Page content hierarchy follows heading guidelines <br />
##Underlined text is avoided unless used for URL navigation<br />
#Do images have alt text? Is the alt text appropriate for the website or software? Do they use a null alt text for decorative images? <br />
#Use [https://www.deque.com/axe/ AXE] ([https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US axe chrome extension]) or another advanced accessibility checker to test the webpages for more specific errors. Record the results. <br />
#Is there a “skip to main content” link?<br />
#Does the site properly use aria landmarks? <br />
#Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
##What barriers are encountered? <br />
##Are any pop-ups or form fields invisible to the screen reader? <br />
##Can a user navigate and use the site without using sight?<br />
##Can a screen reader tell the difference between colored elements?<br />
###Rationale: An example of using color alone to denote meaning is when headings or subheadings are not actually using proper HTML code to mark up the page, a screen reader for example would not be able to recognize that heading or subheading as such, and would read those headings as paragraph text. <br />
#Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups? <br />
#How does the website look or perform on a mobile device? Is there an app? Is it accessible? Test both Android and iOS.<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback. <br />
<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://libguides.colgate.edu/remoteprimarysources Colgate University LibGuide with Appointlet]<br />
**Navigate the site with only a keyboard. <br />
**Is it possible to book an appointment with Sarah only using a keyboard? What about Xena?<br />
**Can a user book an appointment using a screen reader? Can you cancel it? <br />
***Rationale: This page has an inaccessible widget for booking an appointment with Xena. It can’t be activated without the mouse, and the form elements are unlabeled, so a screen reader user wouldn’t know what information to put into the form. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
* [https://www.a11yproject.com/ A11y Project]<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16501Accessibility Auditing Shortlist2023-05-22T18:26:58Z<p>Dkrahmer: /* First Steps */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
# Test out basic keyboard-only access to the website.<br />
## Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes? <br />
### Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit [https://nomouse.org/ Take the #NoMouse Challenge] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics].<br />
## Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
### Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.<br />
## Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?<br />
### Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.<br />
## Does the vendor include a list of keyboard shortcuts? Record that information. <br />
## How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?<br />
# Does the website or software require the user to drag-and-drop to do something, without having an alternative?<br />
## Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
# Does the website use color alone to denote meaning? <br />
## Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
## Does being color blind in some way affect a user’s ability to fully use the site? Is there a difference in color between a visited link and a non-visited link?<br />
### Rationale: Using color alone can affect how users who are color blind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
# Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
## Is any information cut off or made incomprehensible or inaccessible?<br />
## Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All?<br />
### Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%.<br />
# Are the links on the website accessible?<br />
## Are the links a different color from the regular text? Are they underlined?<br />
### Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. [https://webaim.org/resources/contrastchecker/ Use the WebAIM Contrast Checker].<br />
## Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?<br />
### Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
#Does the vendor or website have a page dedicated to accessibility, or a central contact address for accessibility questions and assistance? If so, record the information. <br />
##Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design, or that they don’t value input around accessibility issues.<br />
#Run the [https://wave.webaim.org/ WAVE Automatic Accessibility] tool if it’s a webpage or browser-based program. (This is also available as a browser extension.)<br />
##Report these errors (found in the Details tab), and make a note in the relevant step in the rest of the list: <br />
###Color Contrast (low or very low contrast?)<br />
###Missing Alternative Text<br />
###Missing Link Text<br />
###Broken ARIA<br />
###Heading Structure<br />
###Anything else listed under the Error tab. <br />
##Rationale: To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
#Install and use the [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en HeadingsMap extension] (for Chrome and Firefox) to check the headings on the page. <br />
##Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as a sort of outline structure for a webpage, and HeadingsMap will reveal what that outline looks like.<br />
#Test out basic keyboard access to the website ([https://nomouse.org/ NoMouse.org] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics]). <br />
##Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes?<br />
###Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. <br />
##Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
###Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse. <br />
##Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area? <br />
###Rationale: This tests to see if there are some hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then you need to report that information. <br />
##Does the vendor or website have a list of keyboard commands available to users? Record that information.<br />
#Does the website use color alone to denote meaning? Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
##Does being color blind in some way affect a user’s ability to fully use the site? Is there a significant difference between a visited link and a non-visited link? <br />
###Rationale: Using color alone can affect how users who are colorblind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
#Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
##Is any information cut off or made incomprehensible or inaccessible? <br />
##Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All? <br />
###Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%. <br />
#Are the links on the website accessible? <br />
##Are the links a different color from the regular text? Are they underlined? <br />
###Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. <br />
##Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”? <br />
###Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web. <br />
#Do all videos use subtitles or closed captioning? Are transcripts available for audio content? <br />
##Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually. <br />
#Does the vendor or website have a Voluntary Product Accessibility Template (VPAT) available online? Is there an evaluation available at the [https://www.btaa.org/library/accessibility/library-e-resource-accessibility--testing Big 10 Academic Alliance] site? Record this information. <br />
##Use a search engine of choice to find out!<br />
###Rationale: This document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility. The Big 10 Academic Alliance Library/IT group has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website. <br />
#Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information. <br />
#Does the website or software require the user to drag-and-drop to do something, without having an alternative? <br />
##Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
<br />
===Next Steps===<br />
These tasks should be completed by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually, by someone who has some experience. As you feel more comfortable with the techniques you are learning, you can continue to expand our collection of information about a service. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing.<br />
<br />
#Perform whatever tests you typically perform while doing an accessibility audit, and share your results on the working document. If you have knowledge about VPATs, please share your insights to the VPAT for the service if it exists. <br />
#Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
##Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
#Test out the keyboard accessibility of the software. <br />
##Does the vendor include a list of keyboard shortcuts? Are the shortcuts significantly different from what’s typically used? <br />
##How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated? <br />
##Can a user see the focus state of where the focus is on the webpage? <br />
#Does navigation facilitate ease of use?<br />
##Consistent layout and design; design elements increase predictability<br />
##No broken links, or there is a way to report broken links<br />
##Page content hierarchy follows heading guidelines <br />
##Underlined text is avoided unless used for URL navigation<br />
#Do images have alt text? Is the alt text appropriate for the website or software? Do they use a null alt text for decorative images? <br />
#Use [https://www.deque.com/axe/ AXE] ([https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US axe chrome extension]) or another advanced accessibility checker to test the webpages for more specific errors. Record the results. <br />
#Is there a “skip to main content” link?<br />
#Does the site properly use aria landmarks? <br />
#Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
##What barriers are encountered? <br />
##Are any pop-ups or form fields invisible to the screen reader? <br />
##Can a user navigate and use the site without using sight?<br />
##Can a screen reader tell the difference between colored elements?<br />
###Rationale: An example of using color alone to denote meaning is when headings or subheadings are not actually using proper HTML code to mark up the page, a screen reader for example would not be able to recognize that heading or subheading as such, and would read those headings as paragraph text. <br />
#Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups? <br />
#How does the website look or perform on a mobile device? Is there an app? Is it accessible? Test both Android and iOS.<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback. <br />
<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://libguides.colgate.edu/remoteprimarysources Colgate University LibGuide with Appointlet]<br />
**Navigate the site with only a keyboard. <br />
**Is it possible to book an appointment with Sarah only using a keyboard? What about Xena?<br />
**Can a user book an appointment using a screen reader? Can you cancel it? <br />
***Rationale: This page has an inaccessible widget for booking an appointment with Xena. It can’t be activated without the mouse, and the form elements are unlabeled, so a screen reader user wouldn’t know what information to put into the form. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
* [https://www.a11yproject.com/ A11y Project]<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16500Accessibility Auditing Shortlist2023-05-22T18:23:57Z<p>Dkrahmer: /* First Steps */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
# Test out basic keyboard-only access to the website.<br />
## Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes? <br />
### Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit [https://nomouse.org/ Take the #NoMouse Challenge] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics].<br />
## Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
### Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.<br />
## Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?<br />
### Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.<br />
## Does the vendor include a list of keyboard shortcuts? Record that information. <br />
## How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?<br />
# Does the website or software require the user to drag-and-drop to do something, without having an alternative?<br />
## Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
# Does the website use color alone to denote meaning? <br />
## Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
## Does being color blind in some way affect a user’s ability to fully use the site? Is there a difference in color between a visited link and a non-visited link?<br />
### Rationale: Using color alone can affect how users who are color blind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
#Does the vendor or website have a page dedicated to accessibility, or a central contact address for accessibility questions and assistance? If so, record the information. <br />
##Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design, or that they don’t value input around accessibility issues.<br />
#Run the [https://wave.webaim.org/ WAVE Automatic Accessibility] tool if it’s a webpage or browser-based program. (This is also available as a browser extension.)<br />
##Report these errors (found in the Details tab), and make a note in the relevant step in the rest of the list: <br />
###Color Contrast (low or very low contrast?)<br />
###Missing Alternative Text<br />
###Missing Link Text<br />
###Broken ARIA<br />
###Heading Structure<br />
###Anything else listed under the Error tab. <br />
##Rationale: To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
#Install and use the [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en HeadingsMap extension] (for Chrome and Firefox) to check the headings on the page. <br />
##Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as a sort of outline structure for a webpage, and HeadingsMap will reveal what that outline looks like.<br />
#Test out basic keyboard access to the website ([https://nomouse.org/ NoMouse.org] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics]). <br />
##Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes?<br />
###Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. <br />
##Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
###Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse. <br />
##Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area? <br />
###Rationale: This tests to see if there are some hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then you need to report that information. <br />
##Does the vendor or website have a list of keyboard commands available to users? Record that information.<br />
#Does the website use color alone to denote meaning? Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
##Does being color blind in some way affect a user’s ability to fully use the site? Is there a significant difference between a visited link and a non-visited link? <br />
###Rationale: Using color alone can affect how users who are colorblind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
#Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
##Is any information cut off or made incomprehensible or inaccessible? <br />
##Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All? <br />
###Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%. <br />
#Are the links on the website accessible? <br />
##Are the links a different color from the regular text? Are they underlined? <br />
###Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. <br />
##Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”? <br />
###Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web. <br />
#Do all videos use subtitles or closed captioning? Are transcripts available for audio content? <br />
##Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually. <br />
#Does the vendor or website have a Voluntary Product Accessibility Template (VPAT) available online? Is there an evaluation available at the [https://www.btaa.org/library/accessibility/library-e-resource-accessibility--testing Big 10 Academic Alliance] site? Record this information. <br />
##Use a search engine of choice to find out!<br />
###Rationale: This document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility. The Big 10 Academic Alliance Library/IT group has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website. <br />
#Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information. <br />
#Does the website or software require the user to drag-and-drop to do something, without having an alternative? <br />
##Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
<br />
===Next Steps===<br />
These tasks should be completed by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually, by someone who has some experience. As you feel more comfortable with the techniques you are learning, you can continue to expand our collection of information about a service. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing.<br />
<br />
#Perform whatever tests you typically perform while doing an accessibility audit, and share your results on the working document. If you have knowledge about VPATs, please share your insights to the VPAT for the service if it exists. <br />
#Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
##Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
#Test out the keyboard accessibility of the software. <br />
##Does the vendor include a list of keyboard shortcuts? Are the shortcuts significantly different from what’s typically used? <br />
##How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated? <br />
##Can a user see the focus state of where the focus is on the webpage? <br />
#Does navigation facilitate ease of use?<br />
##Consistent layout and design; design elements increase predictability<br />
##No broken links, or there is a way to report broken links<br />
##Page content hierarchy follows heading guidelines <br />
##Underlined text is avoided unless used for URL navigation<br />
#Do images have alt text? Is the alt text appropriate for the website or software? Do they use a null alt text for decorative images? <br />
#Use [https://www.deque.com/axe/ AXE] ([https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US axe chrome extension]) or another advanced accessibility checker to test the webpages for more specific errors. Record the results. <br />
#Is there a “skip to main content” link?<br />
#Does the site properly use aria landmarks? <br />
#Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
##What barriers are encountered? <br />
##Are any pop-ups or form fields invisible to the screen reader? <br />
##Can a user navigate and use the site without using sight?<br />
##Can a screen reader tell the difference between colored elements?<br />
###Rationale: An example of using color alone to denote meaning is when headings or subheadings are not actually using proper HTML code to mark up the page, a screen reader for example would not be able to recognize that heading or subheading as such, and would read those headings as paragraph text. <br />
#Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups? <br />
#How does the website look or perform on a mobile device? Is there an app? Is it accessible? Test both Android and iOS.<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback. <br />
<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://libguides.colgate.edu/remoteprimarysources Colgate University LibGuide with Appointlet]<br />
**Navigate the site with only a keyboard. <br />
**Is it possible to book an appointment with Sarah only using a keyboard? What about Xena?<br />
**Can a user book an appointment using a screen reader? Can you cancel it? <br />
***Rationale: This page has an inaccessible widget for booking an appointment with Xena. It can’t be activated without the mouse, and the form elements are unlabeled, so a screen reader user wouldn’t know what information to put into the form. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
* [https://www.a11yproject.com/ A11y Project]<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16499Accessibility Auditing Shortlist2023-05-22T18:20:52Z<p>Dkrahmer: /* First Steps */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
# Test out basic keyboard-only access to the website.<br />
## Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes? <br />
### Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit [https://nomouse.org/ Take the #NoMouse Challenge] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics].<br />
## Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
### Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.<br />
## Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?<br />
### Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.<br />
## Does the vendor include a list of keyboard shortcuts? Record that information. <br />
## How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?<br />
<br />
<br />
<br />
<br />
<br />
<br />
#Does the vendor or website have a page dedicated to accessibility, or a central contact address for accessibility questions and assistance? If so, record the information. <br />
##Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design, or that they don’t value input around accessibility issues.<br />
#Run the [https://wave.webaim.org/ WAVE Automatic Accessibility] tool if it’s a webpage or browser-based program. (This is also available as a browser extension.)<br />
##Report these errors (found in the Details tab), and make a note in the relevant step in the rest of the list: <br />
###Color Contrast (low or very low contrast?)<br />
###Missing Alternative Text<br />
###Missing Link Text<br />
###Broken ARIA<br />
###Heading Structure<br />
###Anything else listed under the Error tab. <br />
##Rationale: To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
#Install and use the [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en HeadingsMap extension] (for Chrome and Firefox) to check the headings on the page. <br />
##Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as a sort of outline structure for a webpage, and HeadingsMap will reveal what that outline looks like.<br />
#Test out basic keyboard access to the website ([https://nomouse.org/ NoMouse.org] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics]). <br />
##Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes?<br />
###Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. <br />
##Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
###Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse. <br />
##Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area? <br />
###Rationale: This tests to see if there are some hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then you need to report that information. <br />
##Does the vendor or website have a list of keyboard commands available to users? Record that information.<br />
#Does the website use color alone to denote meaning? Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
##Does being color blind in some way affect a user’s ability to fully use the site? Is there a significant difference between a visited link and a non-visited link? <br />
###Rationale: Using color alone can affect how users who are colorblind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
#Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
##Is any information cut off or made incomprehensible or inaccessible? <br />
##Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All? <br />
###Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%. <br />
#Are the links on the website accessible? <br />
##Are the links a different color from the regular text? Are they underlined? <br />
###Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. <br />
##Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”? <br />
###Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web. <br />
#Do all videos use subtitles or closed captioning? Are transcripts available for audio content? <br />
##Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually. <br />
#Does the vendor or website have a Voluntary Product Accessibility Template (VPAT) available online? Is there an evaluation available at the [https://www.btaa.org/library/accessibility/library-e-resource-accessibility--testing Big 10 Academic Alliance] site? Record this information. <br />
##Use a search engine of choice to find out!<br />
###Rationale: This document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility. The Big 10 Academic Alliance Library/IT group has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website. <br />
#Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information. <br />
#Does the website or software require the user to drag-and-drop to do something, without having an alternative? <br />
##Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
<br />
===Next Steps===<br />
These tasks should be completed by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually, by someone who has some experience. As you feel more comfortable with the techniques you are learning, you can continue to expand our collection of information about a service. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing.<br />
<br />
#Perform whatever tests you typically perform while doing an accessibility audit, and share your results on the working document. If you have knowledge about VPATs, please share your insights to the VPAT for the service if it exists. <br />
#Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
##Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
#Test out the keyboard accessibility of the software. <br />
##Does the vendor include a list of keyboard shortcuts? Are the shortcuts significantly different from what’s typically used? <br />
##How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated? <br />
##Can a user see the focus state of where the focus is on the webpage? <br />
#Does navigation facilitate ease of use?<br />
##Consistent layout and design; design elements increase predictability<br />
##No broken links, or there is a way to report broken links<br />
##Page content hierarchy follows heading guidelines <br />
##Underlined text is avoided unless used for URL navigation<br />
#Do images have alt text? Is the alt text appropriate for the website or software? Do they use a null alt text for decorative images? <br />
#Use [https://www.deque.com/axe/ AXE] ([https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US axe chrome extension]) or another advanced accessibility checker to test the webpages for more specific errors. Record the results. <br />
#Is there a “skip to main content” link?<br />
#Does the site properly use aria landmarks? <br />
#Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
##What barriers are encountered? <br />
##Are any pop-ups or form fields invisible to the screen reader? <br />
##Can a user navigate and use the site without using sight?<br />
##Can a screen reader tell the difference between colored elements?<br />
###Rationale: An example of using color alone to denote meaning is when headings or subheadings are not actually using proper HTML code to mark up the page, a screen reader for example would not be able to recognize that heading or subheading as such, and would read those headings as paragraph text. <br />
#Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups? <br />
#How does the website look or perform on a mobile device? Is there an app? Is it accessible? Test both Android and iOS.<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback. <br />
<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://libguides.colgate.edu/remoteprimarysources Colgate University LibGuide with Appointlet]<br />
**Navigate the site with only a keyboard. <br />
**Is it possible to book an appointment with Sarah only using a keyboard? What about Xena?<br />
**Can a user book an appointment using a screen reader? Can you cancel it? <br />
***Rationale: This page has an inaccessible widget for booking an appointment with Xena. It can’t be activated without the mouse, and the form elements are unlabeled, so a screen reader user wouldn’t know what information to put into the form. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
* [https://www.a11yproject.com/ A11y Project]<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16498Accessibility Auditing Shortlist2023-05-22T18:15:43Z<p>Dkrahmer: /* First Steps */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
# For webpages and electronic documents, check the heading structure of the page by installing and using [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en the HeadingsMap extension] (for Chrome and Firefox). It will display the headings in the order they appear on the page.<br />
## Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. [https://www.w3.org/WAI/tutorials/page-structure/headings/ Learn more about headings].<br />
<br />
<br />
<br />
<br />
<br />
#Does the vendor or website have a page dedicated to accessibility, or a central contact address for accessibility questions and assistance? If so, record the information. <br />
##Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design, or that they don’t value input around accessibility issues.<br />
#Run the [https://wave.webaim.org/ WAVE Automatic Accessibility] tool if it’s a webpage or browser-based program. (This is also available as a browser extension.)<br />
##Report these errors (found in the Details tab), and make a note in the relevant step in the rest of the list: <br />
###Color Contrast (low or very low contrast?)<br />
###Missing Alternative Text<br />
###Missing Link Text<br />
###Broken ARIA<br />
###Heading Structure<br />
###Anything else listed under the Error tab. <br />
##Rationale: To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
#Install and use the [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en HeadingsMap extension] (for Chrome and Firefox) to check the headings on the page. <br />
##Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as a sort of outline structure for a webpage, and HeadingsMap will reveal what that outline looks like.<br />
#Test out basic keyboard access to the website ([https://nomouse.org/ NoMouse.org] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics]). <br />
##Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes?<br />
###Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. <br />
##Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
###Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse. <br />
##Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area? <br />
###Rationale: This tests to see if there are some hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then you need to report that information. <br />
##Does the vendor or website have a list of keyboard commands available to users? Record that information.<br />
#Does the website use color alone to denote meaning? Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
##Does being color blind in some way affect a user’s ability to fully use the site? Is there a significant difference between a visited link and a non-visited link? <br />
###Rationale: Using color alone can affect how users who are colorblind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
#Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
##Is any information cut off or made incomprehensible or inaccessible? <br />
##Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All? <br />
###Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%. <br />
#Are the links on the website accessible? <br />
##Are the links a different color from the regular text? Are they underlined? <br />
###Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. <br />
##Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”? <br />
###Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web. <br />
#Do all videos use subtitles or closed captioning? Are transcripts available for audio content? <br />
##Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually. <br />
#Does the vendor or website have a Voluntary Product Accessibility Template (VPAT) available online? Is there an evaluation available at the [https://www.btaa.org/library/accessibility/library-e-resource-accessibility--testing Big 10 Academic Alliance] site? Record this information. <br />
##Use a search engine of choice to find out!<br />
###Rationale: This document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility. The Big 10 Academic Alliance Library/IT group has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website. <br />
#Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information. <br />
#Does the website or software require the user to drag-and-drop to do something, without having an alternative? <br />
##Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
<br />
===Next Steps===<br />
These tasks should be completed by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually, by someone who has some experience. As you feel more comfortable with the techniques you are learning, you can continue to expand our collection of information about a service. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing.<br />
<br />
#Perform whatever tests you typically perform while doing an accessibility audit, and share your results on the working document. If you have knowledge about VPATs, please share your insights to the VPAT for the service if it exists. <br />
#Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
##Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
#Test out the keyboard accessibility of the software. <br />
##Does the vendor include a list of keyboard shortcuts? Are the shortcuts significantly different from what’s typically used? <br />
##How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated? <br />
##Can a user see the focus state of where the focus is on the webpage? <br />
#Does navigation facilitate ease of use?<br />
##Consistent layout and design; design elements increase predictability<br />
##No broken links, or there is a way to report broken links<br />
##Page content hierarchy follows heading guidelines <br />
##Underlined text is avoided unless used for URL navigation<br />
#Do images have alt text? Is the alt text appropriate for the website or software? Do they use a null alt text for decorative images? <br />
#Use [https://www.deque.com/axe/ AXE] ([https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US axe chrome extension]) or another advanced accessibility checker to test the webpages for more specific errors. Record the results. <br />
#Is there a “skip to main content” link?<br />
#Does the site properly use aria landmarks? <br />
#Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
##What barriers are encountered? <br />
##Are any pop-ups or form fields invisible to the screen reader? <br />
##Can a user navigate and use the site without using sight?<br />
##Can a screen reader tell the difference between colored elements?<br />
###Rationale: An example of using color alone to denote meaning is when headings or subheadings are not actually using proper HTML code to mark up the page, a screen reader for example would not be able to recognize that heading or subheading as such, and would read those headings as paragraph text. <br />
#Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups? <br />
#How does the website look or perform on a mobile device? Is there an app? Is it accessible? Test both Android and iOS.<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback. <br />
<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://libguides.colgate.edu/remoteprimarysources Colgate University LibGuide with Appointlet]<br />
**Navigate the site with only a keyboard. <br />
**Is it possible to book an appointment with Sarah only using a keyboard? What about Xena?<br />
**Can a user book an appointment using a screen reader? Can you cancel it? <br />
***Rationale: This page has an inaccessible widget for booking an appointment with Xena. It can’t be activated without the mouse, and the form elements are unlabeled, so a screen reader user wouldn’t know what information to put into the form. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
* [https://www.a11yproject.com/ A11y Project]<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16497Accessibility Auditing Shortlist2023-05-22T18:11:46Z<p>Dkrahmer: /* First Steps */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].<br />
## Report these errors (found in the Details tab)<br />
### Color Contrast (low or very low contrast?)<br />
### Missing Alternative Text<br />
### Missing Link Text<br />
### Broken ARIA<br />
### Heading Structure<br />
### Anything else listed under the Error tab.<br />
## To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
<br />
<br />
<br />
<br />
#Does the vendor or website have a page dedicated to accessibility, or a central contact address for accessibility questions and assistance? If so, record the information. <br />
##Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design, or that they don’t value input around accessibility issues.<br />
#Run the [https://wave.webaim.org/ WAVE Automatic Accessibility] tool if it’s a webpage or browser-based program. (This is also available as a browser extension.)<br />
##Report these errors (found in the Details tab), and make a note in the relevant step in the rest of the list: <br />
###Color Contrast (low or very low contrast?)<br />
###Missing Alternative Text<br />
###Missing Link Text<br />
###Broken ARIA<br />
###Heading Structure<br />
###Anything else listed under the Error tab. <br />
##Rationale: To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
#Install and use the [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en HeadingsMap extension] (for Chrome and Firefox) to check the headings on the page. <br />
##Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as a sort of outline structure for a webpage, and HeadingsMap will reveal what that outline looks like.<br />
#Test out basic keyboard access to the website ([https://nomouse.org/ NoMouse.org] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics]). <br />
##Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes?<br />
###Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. <br />
##Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
###Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse. <br />
##Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area? <br />
###Rationale: This tests to see if there are some hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then you need to report that information. <br />
##Does the vendor or website have a list of keyboard commands available to users? Record that information.<br />
#Does the website use color alone to denote meaning? Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
##Does being color blind in some way affect a user’s ability to fully use the site? Is there a significant difference between a visited link and a non-visited link? <br />
###Rationale: Using color alone can affect how users who are colorblind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
#Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
##Is any information cut off or made incomprehensible or inaccessible? <br />
##Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All? <br />
###Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%. <br />
#Are the links on the website accessible? <br />
##Are the links a different color from the regular text? Are they underlined? <br />
###Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. <br />
##Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”? <br />
###Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web. <br />
#Do all videos use subtitles or closed captioning? Are transcripts available for audio content? <br />
##Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually. <br />
#Does the vendor or website have a Voluntary Product Accessibility Template (VPAT) available online? Is there an evaluation available at the [https://www.btaa.org/library/accessibility/library-e-resource-accessibility--testing Big 10 Academic Alliance] site? Record this information. <br />
##Use a search engine of choice to find out!<br />
###Rationale: This document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility. The Big 10 Academic Alliance Library/IT group has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website. <br />
#Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information. <br />
#Does the website or software require the user to drag-and-drop to do something, without having an alternative? <br />
##Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
<br />
===Next Steps===<br />
These tasks should be completed by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually, by someone who has some experience. As you feel more comfortable with the techniques you are learning, you can continue to expand our collection of information about a service. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing.<br />
<br />
#Perform whatever tests you typically perform while doing an accessibility audit, and share your results on the working document. If you have knowledge about VPATs, please share your insights to the VPAT for the service if it exists. <br />
#Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
##Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
#Test out the keyboard accessibility of the software. <br />
##Does the vendor include a list of keyboard shortcuts? Are the shortcuts significantly different from what’s typically used? <br />
##How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated? <br />
##Can a user see the focus state of where the focus is on the webpage? <br />
#Does navigation facilitate ease of use?<br />
##Consistent layout and design; design elements increase predictability<br />
##No broken links, or there is a way to report broken links<br />
##Page content hierarchy follows heading guidelines <br />
##Underlined text is avoided unless used for URL navigation<br />
#Do images have alt text? Is the alt text appropriate for the website or software? Do they use a null alt text for decorative images? <br />
#Use [https://www.deque.com/axe/ AXE] ([https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US axe chrome extension]) or another advanced accessibility checker to test the webpages for more specific errors. Record the results. <br />
#Is there a “skip to main content” link?<br />
#Does the site properly use aria landmarks? <br />
#Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
##What barriers are encountered? <br />
##Are any pop-ups or form fields invisible to the screen reader? <br />
##Can a user navigate and use the site without using sight?<br />
##Can a screen reader tell the difference between colored elements?<br />
###Rationale: An example of using color alone to denote meaning is when headings or subheadings are not actually using proper HTML code to mark up the page, a screen reader for example would not be able to recognize that heading or subheading as such, and would read those headings as paragraph text. <br />
#Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups? <br />
#How does the website look or perform on a mobile device? Is there an app? Is it accessible? Test both Android and iOS.<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback. <br />
<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://libguides.colgate.edu/remoteprimarysources Colgate University LibGuide with Appointlet]<br />
**Navigate the site with only a keyboard. <br />
**Is it possible to book an appointment with Sarah only using a keyboard? What about Xena?<br />
**Can a user book an appointment using a screen reader? Can you cancel it? <br />
***Rationale: This page has an inaccessible widget for booking an appointment with Xena. It can’t be activated without the mouse, and the form elements are unlabeled, so a screen reader user wouldn’t know what information to put into the form. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
* [https://www.a11yproject.com/ A11y Project]<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16496Accessibility Auditing Shortlist2023-05-22T18:08:46Z<p>Dkrahmer: /* First Steps */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.<br />
<br />
# Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? If so, record the information. <br />
## Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design or that they don’t value input about accessibility issues. <br />
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ Voluntary Product Accessibility Template] (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.<br />
## Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The [https://libraryaccessibility.org/ Big 10 Library Accessibility Alliance] has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.<br />
<br />
<br />
<br />
#Does the vendor or website have a page dedicated to accessibility, or a central contact address for accessibility questions and assistance? If so, record the information. <br />
##Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design, or that they don’t value input around accessibility issues.<br />
#Run the [https://wave.webaim.org/ WAVE Automatic Accessibility] tool if it’s a webpage or browser-based program. (This is also available as a browser extension.)<br />
##Report these errors (found in the Details tab), and make a note in the relevant step in the rest of the list: <br />
###Color Contrast (low or very low contrast?)<br />
###Missing Alternative Text<br />
###Missing Link Text<br />
###Broken ARIA<br />
###Heading Structure<br />
###Anything else listed under the Error tab. <br />
##Rationale: To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
#Install and use the [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en HeadingsMap extension] (for Chrome and Firefox) to check the headings on the page. <br />
##Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as a sort of outline structure for a webpage, and HeadingsMap will reveal what that outline looks like.<br />
#Test out basic keyboard access to the website ([https://nomouse.org/ NoMouse.org] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics]). <br />
##Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes?<br />
###Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. <br />
##Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
###Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse. <br />
##Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area? <br />
###Rationale: This tests to see if there are some hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then you need to report that information. <br />
##Does the vendor or website have a list of keyboard commands available to users? Record that information.<br />
#Does the website use color alone to denote meaning? Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
##Does being color blind in some way affect a user’s ability to fully use the site? Is there a significant difference between a visited link and a non-visited link? <br />
###Rationale: Using color alone can affect how users who are colorblind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
#Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
##Is any information cut off or made incomprehensible or inaccessible? <br />
##Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All? <br />
###Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%. <br />
#Are the links on the website accessible? <br />
##Are the links a different color from the regular text? Are they underlined? <br />
###Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. <br />
##Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”? <br />
###Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web. <br />
#Do all videos use subtitles or closed captioning? Are transcripts available for audio content? <br />
##Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually. <br />
#Does the vendor or website have a Voluntary Product Accessibility Template (VPAT) available online? Is there an evaluation available at the [https://www.btaa.org/library/accessibility/library-e-resource-accessibility--testing Big 10 Academic Alliance] site? Record this information. <br />
##Use a search engine of choice to find out!<br />
###Rationale: This document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility. The Big 10 Academic Alliance Library/IT group has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website. <br />
#Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information. <br />
#Does the website or software require the user to drag-and-drop to do something, without having an alternative? <br />
##Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
<br />
===Next Steps===<br />
These tasks should be completed by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually, by someone who has some experience. As you feel more comfortable with the techniques you are learning, you can continue to expand our collection of information about a service. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing.<br />
<br />
#Perform whatever tests you typically perform while doing an accessibility audit, and share your results on the working document. If you have knowledge about VPATs, please share your insights to the VPAT for the service if it exists. <br />
#Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
##Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
#Test out the keyboard accessibility of the software. <br />
##Does the vendor include a list of keyboard shortcuts? Are the shortcuts significantly different from what’s typically used? <br />
##How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated? <br />
##Can a user see the focus state of where the focus is on the webpage? <br />
#Does navigation facilitate ease of use?<br />
##Consistent layout and design; design elements increase predictability<br />
##No broken links, or there is a way to report broken links<br />
##Page content hierarchy follows heading guidelines <br />
##Underlined text is avoided unless used for URL navigation<br />
#Do images have alt text? Is the alt text appropriate for the website or software? Do they use a null alt text for decorative images? <br />
#Use [https://www.deque.com/axe/ AXE] ([https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US axe chrome extension]) or another advanced accessibility checker to test the webpages for more specific errors. Record the results. <br />
#Is there a “skip to main content” link?<br />
#Does the site properly use aria landmarks? <br />
#Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
##What barriers are encountered? <br />
##Are any pop-ups or form fields invisible to the screen reader? <br />
##Can a user navigate and use the site without using sight?<br />
##Can a screen reader tell the difference between colored elements?<br />
###Rationale: An example of using color alone to denote meaning is when headings or subheadings are not actually using proper HTML code to mark up the page, a screen reader for example would not be able to recognize that heading or subheading as such, and would read those headings as paragraph text. <br />
#Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups? <br />
#How does the website look or perform on a mobile device? Is there an app? Is it accessible? Test both Android and iOS.<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback. <br />
<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://libguides.colgate.edu/remoteprimarysources Colgate University LibGuide with Appointlet]<br />
**Navigate the site with only a keyboard. <br />
**Is it possible to book an appointment with Sarah only using a keyboard? What about Xena?<br />
**Can a user book an appointment using a screen reader? Can you cancel it? <br />
***Rationale: This page has an inaccessible widget for booking an appointment with Xena. It can’t be activated without the mouse, and the form elements are unlabeled, so a screen reader user wouldn’t know what information to put into the form. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
* [https://www.a11yproject.com/ A11y Project]<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmerhttps://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&diff=16495Accessibility Auditing Shortlist2023-05-22T17:42:01Z<p>Dkrahmer: /* Checklist */</p>
<hr />
<div>This list was initially created in the #IT subgroup slack channel, and updated in May 2023. Find more auditing ideas from the big [[Accessibility Auditing Resources]] Page. <br />
<br />
==Introduction==<br />
The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the [[Digital Accessibility Group|DLF Digital Accessibility Working Group Wiki]]. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.<br />
<br />
If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc Accessibility Assessment Template] for that technology. ([[IT_and_Development#Group_Organizers |Contact the Group Organizers]] for more information.)<br />
<br />
==What do we mean by accessibility?== <br />
In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone in a very noisy place.<br />
<br />
As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in this duty.<br />
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].<br />
<br />
==Checklist==<br />
Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. The DLF DAWG team uses these steps and [https://docs.google.com/document/d/1YVMgN2BSx1xG7wTqUgOtdpG5xOzCaZsN0PP1vqeGOyE/edit#heading=h.ignecjocxmlc the accompanying template] for our website reviews. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines.<br />
<br />
===First Steps===<br />
These tasks can be completed by anyone, even if you have no experience in web design or accessibility auditing. Web Accessibility is easier to test for a layperson than software accessibility, but you can still do some tasks.<br />
<br />
#Does the vendor or website have a page dedicated to accessibility, or a central contact address for accessibility questions and assistance? If so, record the information. <br />
##Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design, or that they don’t value input around accessibility issues.<br />
#Run the [https://wave.webaim.org/ WAVE Automatic Accessibility] tool if it’s a webpage or browser-based program. (This is also available as a browser extension.)<br />
##Report these errors (found in the Details tab), and make a note in the relevant step in the rest of the list: <br />
###Color Contrast (low or very low contrast?)<br />
###Missing Alternative Text<br />
###Missing Link Text<br />
###Broken ARIA<br />
###Heading Structure<br />
###Anything else listed under the Error tab. <br />
##Rationale: To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.<br />
#Install and use the [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en HeadingsMap extension] (for Chrome and Firefox) to check the headings on the page. <br />
##Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as a sort of outline structure for a webpage, and HeadingsMap will reveal what that outline looks like.<br />
#Test out basic keyboard access to the website ([https://nomouse.org/ NoMouse.org] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics]). <br />
##Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes?<br />
###Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. <br />
##Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?<br />
###Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse. <br />
##Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area? <br />
###Rationale: This tests to see if there are some hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then you need to report that information. <br />
##Does the vendor or website have a list of keyboard commands available to users? Record that information.<br />
#Does the website use color alone to denote meaning? Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.<br />
##Does being color blind in some way affect a user’s ability to fully use the site? Is there a significant difference between a visited link and a non-visited link? <br />
###Rationale: Using color alone can affect how users who are colorblind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.<br />
#Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.<br />
##Is any information cut off or made incomprehensible or inaccessible? <br />
##Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All? <br />
###Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%. <br />
#Are the links on the website accessible? <br />
##Are the links a different color from the regular text? Are they underlined? <br />
###Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. <br />
##Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”? <br />
###Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web. <br />
#Do all videos use subtitles or closed captioning? Are transcripts available for audio content? <br />
##Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually. <br />
#Does the vendor or website have a Voluntary Product Accessibility Template (VPAT) available online? Is there an evaluation available at the [https://www.btaa.org/library/accessibility/library-e-resource-accessibility--testing Big 10 Academic Alliance] site? Record this information. <br />
##Use a search engine of choice to find out!<br />
###Rationale: This document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility. The Big 10 Academic Alliance Library/IT group has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website. <br />
#Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information. <br />
#Does the website or software require the user to drag-and-drop to do something, without having an alternative? <br />
##Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.<br />
<br />
===Next Steps===<br />
These tasks should be completed by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually, by someone who has some experience. As you feel more comfortable with the techniques you are learning, you can continue to expand our collection of information about a service. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing.<br />
<br />
#Perform whatever tests you typically perform while doing an accessibility audit, and share your results on the working document. If you have knowledge about VPATs, please share your insights to the VPAT for the service if it exists. <br />
#Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.<br />
##Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).<br />
#Test out the keyboard accessibility of the software. <br />
##Does the vendor include a list of keyboard shortcuts? Are the shortcuts significantly different from what’s typically used? <br />
##How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated? <br />
##Can a user see the focus state of where the focus is on the webpage? <br />
#Does navigation facilitate ease of use?<br />
##Consistent layout and design; design elements increase predictability<br />
##No broken links, or there is a way to report broken links<br />
##Page content hierarchy follows heading guidelines <br />
##Underlined text is avoided unless used for URL navigation<br />
#Do images have alt text? Is the alt text appropriate for the website or software? Do they use a null alt text for decorative images? <br />
#Use [https://www.deque.com/axe/ AXE] ([https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US axe chrome extension]) or another advanced accessibility checker to test the webpages for more specific errors. Record the results. <br />
#Is there a “skip to main content” link?<br />
#Does the site properly use aria landmarks? <br />
#Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)<br />
##What barriers are encountered? <br />
##Are any pop-ups or form fields invisible to the screen reader? <br />
##Can a user navigate and use the site without using sight?<br />
##Can a screen reader tell the difference between colored elements?<br />
###Rationale: An example of using color alone to denote meaning is when headings or subheadings are not actually using proper HTML code to mark up the page, a screen reader for example would not be able to recognize that heading or subheading as such, and would read those headings as paragraph text. <br />
#Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups? <br />
#How does the website look or perform on a mobile device? Is there an app? Is it accessible? Test both Android and iOS.<br />
<br />
==Assistive Technology User Testing==<br />
Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. <br />
<br />
If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback. <br />
<br />
<br />
==Websites you can practice on==<br />
* [https://prezi.com Prezi.com]<br />
** This is a good site to test the WAVE tool with, as it has many errors. <br />
* [https://libguides.colgate.edu/remoteprimarysources Colgate University LibGuide with Appointlet]<br />
**Navigate the site with only a keyboard. <br />
**Is it possible to book an appointment with Sarah only using a keyboard? What about Xena?<br />
**Can a user book an appointment using a screen reader? Can you cancel it? <br />
***Rationale: This page has an inaccessible widget for booking an appointment with Xena. It can’t be activated without the mouse, and the form elements are unlabeled, so a screen reader user wouldn’t know what information to put into the form. <br />
* [https://pizzahut.com Pizzahut.com]<br />
** Can you order a pizza using just the keyboard? <br />
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]<br />
* [https://www.a11yproject.com/ A11y Project]<br />
<br />
<br />
<br />
<br />
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].</div>Dkrahmer