audio version (opens in a new tab)
Introduction
My blog this week is a follow-up to my previous one.
Focused on a webinar about creating accessible documents. I also referenced a webinar about the same subject from
“RAISE Center | Resources for Access, Independence, Self-Advocacy and Employment”.
On December 2, 2021, I attended an informal workshop on the same subject from RAISE. To my knowledge, the event was not recorded because it was an informal question-and-answer workshop. I choose to share my takeaways as a participant. In my article this week, I will summarize what I learned and provide my own reflections.
The virtual workshop moderated by RAISE was a question-and-answer session between participants and a representative of
American Foundation for the Blind (AFB).
PDF Accessibility
For accessibility, it was recommended for PDF documents to be text-based. PDF accessibility can be challenging, depending on how it is created. One of the presenters recommended PDFs documents created originally as Word documents for accessibility. The presenter also recommended using Adobe Reader when checking the accessibility of a PDF. The moderator from RAISE asked if online resources should be available in both PDF and Word. The AFB presenter said yes. He also said it is easier to check accessibility in a Word document compared to PDF. The reason is that the automated accessibility tool of Adobe is more limited. Example: Adobe’s accessibility tool cannot determine if columns go across the page. However, Adobe’s accessibility tool can see if relevant tags are used such as headings. The questions then focused on web site accessibility in particular.
Web Site Accessibility
Visual Effects
Color itself does not convey meaning for screen reader users. Zooming into content can be important for low-vision users. Ideally, content should not collapse visually when zooming is used. It is acceptable to hide content on a web site if it is not crucial. This can be accomplished by using a menu on the web site. It is also important for fonts to be between 10-point and 12-point, not small. There were also observations about keyboard usage and other web page accessibility topics.
Keyboard Usage
Pages can be navigated with a screen reader using arrow keys or tab. When tabbing through a page, the user should know what is being focused on. Menus can usually be opened with space. Pressing enter enables a link, button or menu to be activated. Date tickers used for selecting a date can sometimes be challenging for keyboard users. An alternative for that issue would be typing in the date.
Web Page Accessibility
“Skip to Main Content” links enable a screen reader user to go to the main section of a page. Links and images need text descriptions for screen reader users. Additionally, pressing h while using a screen reader enables skipping through headings. Press g enables the screen reader to skip by graphics. It was pointed out that some people with disabilities use a keyboard without a screen reader. Ideally, page content should be inside a region. Additionally, elements of forms should be labeled sufficiently. I will now provide my own reflections.
Blake’s Reflections
From my perspective as a participant who is blind, AFB did a fantastic job pinpointing accessibility areas to focus on and answering various questions posed during the workshop. I also found it useful that participants could hear the AFB representative’s screen reader while navigating material. The workshop was perfect timing because I experienced an accessibility barrier referenced by AFB while I was visiting a web site recently. I chose not to share verbally during the workshop for two reasons. First reason: It became immediately clear to me at beginning of the workshop that the questions were primarily or completely from content creators seeking input from AFB. I did not feel comfortable speaking up because I was not the intended audience. Second reason: I also chose to not deprive someone else of the microphone during the limited time available. However, I choose to share my experience here as an example of what a web designer should not do. I visited a web site several days ago in order to complete a task in my personal life. One of the screens I encountered had a graphical calendar which would not allow the date to be typed. I was able to overcome the accessibility barrier by receiving sighted help from a family member. That individual selected the necessary date using a mouse so that I could proceed. I am definitely thankful I could get sighted assistance when needed. I mention my recent experience to show that a date ticker requiring mouse usage can pose a literal barrier for some people with disabilities. If you are a web site developer reading my article, I encourage using a date ticker which allows dates to be typed. Bottom line: Considering accessibility for people with disabilities when creating digital content can lead to a positive experience if the information is sufficiently accessible.
Question for Readers
Are there specific accessibility subjects discussed above which you would like to learn more about through my blog? I will return with another article.
Blake's talk 