- An article by Rhea Althea Guntalilib, describing her experience of using the new “VoiceOver Recognition” features of iOS 14. It is a collection of tools including “Screen Recognition” (which I’ll talk about below), “Text Recognition” (which detects text found in images) and “Image Descriptions” (which describes image contents). These features are accessible via Settings > Accessibility > VoiceOver and can then be quick-selected via the VoiceOver rotor.
- I covered Screen Recognition in dai11y 22/12/2020: “It uses AI to detect interactable elements on the screen, even when such elements aren’t properly labelled / exposed to assistive technology. It has the potential to allow blind users to use apps that are otherwise inaccessible.”
- Rhea found the Image Descriptions improved her experience of the Facebook and Instagram apps, and also Text Recognition was great at describing her screenshots of captured text messages. Screen Recognition came in handy for her banking apps, which otherwise have no accessible way of transferring funds or paying bills. But she did find she had to turn off Screen Recognition in places, e.g. to properly access the list of available banks, as it would interfere with how VoiceOver worked. Other apps, such as email, had attachments that could not be processed by VoiceOver Recognition.
- In summary, whilst it has some glitches and limitations, it has “delivered many improvements in the user experience of a blind iOS customer”.
- Think you know SVGs? This article is worth a read – you just might learn something.
- SVGs have an implicit WAI-ARIA role of “graphics-document“. You should only change this if the SVG only contains an image; an attribute of
role="graphics-symbol"would be appropriate.
- Hide decorative SVGs from screen readers using
role="presentation", as this doesn’t hide the contents of the SVG from screen readers.
- SVGs can have a
<title>attribute which acts like an
altattribute on a normal image. It has to be the first child element within the
<svg>. There is also an optional
<desc>element which can follow this, and should be used to present more detailed textual information. Browser support for both of these is good but not 100%;
aria-labelcan be added for wider support.
- It’s not enough to just use semantic markup to, say, create a list in HTML (the “what”), and mark it up with a
role="menu"(the “how it’s supposed to work”). We also often need to label the list, to explain “why” it’s there. For example, an
aria-label="Main menu"to give some extra context to screen reader users.
- This article describes how and when you should name things in HTML. It covers the basics, such as associating a label with an input, which effectively gives the input a name, but it also covers the stuff that is more easily omitted, such as applying a label to your ARIA regions.
- Not every landmark needs a name, but any
regionshould, as well as
main(it’s good practice to associate the H1 element with the main content in your page via
aria-labelledby). Landmarks that appear once per page, such as
banner, should not have a name.
- An interesting article, worth reading as it goes against the current narrative that the disabled community have benefited from the move to online tuition. It covers university undergraduates and graduates in America.
- “Only 20% of [American] undergraduate students with disabilities reported enjoying online learning, and over one third of students with disabilities reported no increased satisfaction with online learning in general”.
- The story changes slightly for graduate students with disabilities, who liked online learning more than those without disabilities, but also felt less productive and more disconnected from professors.
- That said, there were some areas where “disabled students did describe a greater satisfaction than non-disabled students”, such as “comfort levels in speaking up in class” and “connection with other students”.
- Learning from home rather than university “meant being removed from the protective factor of the university”. Shockingly, only 40% of undergraduate students with multiple disabilities have a “place to live that is free from physical or emotional violence or abuse”.
- In partnership with RNIB, Kellogg’s has trialled including NaviLens codes on its packaging, giving visually impaired customers a way of scanning products to find out their ingredients, allergen and recycling information.
- NaviLens codes work in a similar way to QR codes, but can be detected “in a fraction of the time, from up to three metres away”. RNIB and Kellogg’s deduced that NaviLens catered to more people with sight loss, rather than those with specific requirements (such as braille users).
- 97% of the trial’s participants agreed they’d like to see more of these accessibility features available on grocery packaging.
- There’s a 5 minute video explaining more about the project.
- The famous WebAIM survey this year had 1568 responses, mostly from North America and Europe, with a pretty even age split. 92.3% of respondents said they have a disability, almost 80% of which was blindness.
- 57.5% of respondents class themselves as “advanced” screen reader users, versus 37.4% “intermediate” and 5.1% “beginner”. This roughly correlates with their self-assessed levels of “Internet Proficiency”.
- JAWS is the primary screen reader for over half of respondents, followed by NVDA on around 30%. VoiceOver counts for just 6.5%. This is a decline for NVDA and VoiceOver compared to previous years. Windows Narrator is the primary reader of less than 1% of respondents, but is “commonly used” by 41% of them, compared to 30% in 2019.
- Chrome is the browser of choice for 53.6% of respondents, followed by Edge at 18.4% and Firefox at 16.5%. Chrome and Edge usage has increased notably. JAWS with Chrome is by far the most common screen reader & browser combination, at 32.5%. 91.1% of respondents use Windows, vs 6.5% on Mac.
- 72% use iOS mobile devices, vs 25.8% on Android. This corresponds roughly with mobile screen reader usage of 71.5% on VoiceOver and 29.1% on TalkBack, and with choice of browser (Safari: 61.6%, Chrome: 24.2%).
- Almost two thirds of screen readers report that they are “very satisfied” with their primary screen reader, and almost a third “somewhat satisfied”.
- When asked how often they use “skip links” when available, 17.5% said “Always”, 15% said “Often”, 29.7% said “Sometimes”, 22.7% said “Seldom” and 15% said “Never”. Whilst very mixed results, these are largely unchanged from the 2017 survey.
- Around 39% say web content has become more accessible this year, but around 42% say there has been no change, and 18.5% say content has become less accessible.
- The majority of screen reader users navigate pages by working through the headings first. About 85% of users find the use of heading levels either very useful or somewhat useful.
- Heather Waroff, Senior Designer at Microsoft, writes about interaction design. The most useful part of the article for me was the list below, developed “in conjunction with Accessibility specialists”. It describes the types of motion that are considered safe (good), risky (‘it depends’), and non-compliant (bad).
- Safe Motion:
- Motion under 5 seconds, of the following types:
- Color Transitions
- Glyph Transformations
- Motion under 5 seconds, of the following types:
- Risky motion
- Any motion longer than 5 seconds
- Background Parallax
- Object Parallax
- Bouncing Effects
- Fast Effects
- Image Masking on Scroll
- Full Width Mask on Scroll
- Zoom on Scroll
- Scale on Scroll
- Non-compliant motion
- Any motion longer than 5 seconds without a pause button
- Strobe Effects
- Rotate on Scroll
- Fast exit on Scroll
- Horizontal Directional Scrolling
Did you know that you can subscribe to dai11y, week11y, fortnight11y or month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.