In the early afternoon panel discussion, Nathan Rowland was talking about building inaccessible products when he dropped this gem:

There is nothing more permanent than a temporary solution.

I love this! I caught up with Nathan afterwards and he said it was something his grandfather used to say about woodworking. It goes back to that job-half-done idea, but makes it an even scarier prospect.

We design and build digital products for other people to use, and other people might (will!) use our products in ways we didn’t expect. Accessibility is partly about anticipating this unknown.

If we ship a subpar feature or update to our product, what’s the likelihood of going back to put it right?

Other priorities creep in, team members change, and that temporarily inaccessible work is forgotten. It gets built on top of. And the longer it sits there, the more expensive and awkward it is to fix.

That doesn’t mean everything has to be perfect; it just means accessibility can’t be treated as something we’ll tidy up later.

The article Do it properly now appeared first on www.tempertemper.net.

Pie charts, line graphs, bar and column charts (let’s just call them all ‘charts’ for ease) are really useful, visual ways to present data, and we’d include one on a webpage using an image, like a PNG or SVG.

Accessible PNGs

I say ‘PNGs’, but these could be any other image format, like WebP, AVIF, or even JPG. The mechanism we’d use to embed them on our page would be the <img /> element:

<img src="my-great-chart.png" alt="A description of the information the chart conveys" />

Depending on the complexity of the chart, our alt text could be doing a lot of work here. In principle, that’s fine, as the alt attribute can contain as many characters as you need, but the problem is that there’s no way of introducing any meaning to the content in alt text; it’s just a wall of unstructured text.

Here’s an example with some made-up figures about people’s favourite characters from the original Star Wars trilogy:

<img src="star-wars-favourites.png" alt="Pie chart showing that 22% chose Han Solo, 18% chose Darth Vader, 15% chose Princess Leia, 12% chose Chewbacca, 9% chose Luke Skywalker, 7% chose Yoda, 6% chose Obi-Wan Kenobi, 4% chose Lando Calrissian, 3% chose R2-D2, 2% chose C-3PO, and 2% chose other characters." />

That’s a fairly typical amount of information for a chart, and it takes a fair amount of concentration to make sense of, especially with so much repetitive language. Imagine more complex charts, like a stacked column chart or a best-fit line chart.

Before you mention longdesc…

I know what you’re thinking: there’s the longdesc attribute, which allows us to reference a structured HTML document:

<img src="star-wars-favourites.png" longdesc="star-wars-favourites-description.html" />

Although browser support still appears to be there, longdesc is long deprecated so definitely not recommended.

Accessible SVGs

So if alt text isn’t ideal, and longdesc is out, maybe a more complex image format like SVG is the answer?

We could reference an SVG file just as we did with the PNG in our last example, but for inline SVGs the result is exactly the same; a big lump of unstructured descriptive text:

<svg role="img" aria-labelledby="title description" xmlns="http://www.w3.org/2000/svg">
    <title id="title">Pie chart showing people's favourite characters from the original Star Wars trilogy</title>
    <desc id="description">22% chose Han Solo, 18% chose Darth Vader, 15% chose Princess Leia, 12% chose Chewbacca, 9% chose Luke Skywalker, 7% chose Yoda, 6% chose Obi-Wan Kenobi, 4% chose Lando Calrissian, 3% chose R2-D2, 2% chose C-3PO, and 2% chose other characters.</desc>
    <!-- SVG coordinates -->
</svg>

ARIA in SVG

But we’ve been ignoring SVG’s superpowers! SVG is markup, so ARIA can be used to add semantics to the elements that make it up.

In Accessible SVG line graphs, Léonie Watson goes into detail about how we can make purposeful use of SVG’s group (<g>) element and various ARIA role attributes to give the chart table semantics. A chart is a visual representation of tabular data, after all!

For our Star Wars pie chart, we could use:

• role="table" for the containing group
• role="row" for each character
• role="columnheader" to label each column of information (character name, and percentage of votes)
• role="rowheader" for each character name
• role="cell" for each percentage value

Visually a chart; semantically a table.

One thing visually, another non-visually

I love the ARIA in SVG approach, but it’s fiddly enough to make me wonder if there’s a simpler approach. We could separate the two things:

• An SVG chart that’s hidden from assistive technologies with role="presentation" or aria-hidden="true"
• An HTML table that’s hidden visually with CSS, but still available to screen reader users

This way, sighted users would see the chart and screen reader users would get the data in an HTML table. That would work, but it still assumes the table is only useful to screen reader users.

Just show the underlying data

Maybe we should stop treating the table as an accessibility-only fallback? I reckon it could be even better to present both the visualisation and the underlying data. After all, some people might prefer rows and columns to a chart.

The way I’d probably approach this is to ensure the chart doesn’t get picked up by assistive technology like screen reader software at all, as we did before:

<svg role="presentation" xmlns="http://www.w3.org/2000/svg">
    <!-- SVG contents -->
</svg>

And then our table:

<table>
    <caption>Favourite characters from the original Star Wars trilogy</caption>
    <tr>
        <th>Character</th>
        <th>Percentage of votes</th>
    </tr>
    <tr>
        <td>Han Solo</td>
        <td>22%</td>
    </tr>
    <tr>
        <td>Darth Vader</td>
        <td>18%</td>
    </tr>
    <!-- The rest of the characters -->
</table>

If your table has a lot of data, you could save some unnecessary scrolling for users who prefer the chart by wrapping it in a <details>/<summary> element.

Note: it’s totally valid to expose the chart to screen reader users if the visual presentation is relevant; just make sure the alternative text describes the visual presentation, not the data that’s already available in the table.

So what to do?

For screen reader users, a simple chart with the data in the alt text might be okay, but more often than not we probably want to present the data in tabular format, which is easier to navigate, compare, and understand. Going one step further by accompanying the chart with a table is an even more robust approach as it also allows sighted users to choose how best to absorb the information.

So do charts and graphs need to be accessible? Yes and no. The chart image itself doesn’t always need to be exposed to assistive technologies, but the information it communicates must be accessible.

The article Do graphs and charts need to be accessible? appeared first on www.tempertemper.net.

You know how pernickety I can get about what things are called; I mean, I wrote over 600 words on why not to use ‘headers’ and ‘headings’ interchangeably. So allow me to dig into why the ‘label’ bit of aria-label gets on my nerves.

Let’s use the Web Content Accessibility Guidelines (WCAG) as our reference point for the terminology. Here’s their definition for ‘label’:

text or other component with a text alternative that is presented to a user to identify a component within web content

It’s referring to what is presented visually; usually text or something else with a ‘text alternative’, like an icon.

WCAG then goes on to define a ‘name’ as:

text by which software can identify a component within web content to the user

So this is always text, and specifically about how software uses text to convey something to the user. It’s about the underlying accessible name. That might match the label, but it won’t if the label is:

• an icon
• a shortened version of a longer, more descriptive name, relying on surrounding content for visual context

Maddeningly, the ARIA spec describes aria-label in terms of it being a ‘name’ too:

It provides the user with a recognizable name of the object. The most common accessibility API mapping for a label is the accessible name property

So my article about aria-label for <nav> elements was much easier to read when talking about aria-labels as if they were labels, but it wasn’t technically correct. If aria-label is always used to give something a ‘name’, wouldn’t aria-name have made more sense…?

The article A bugbear about aria-label appeared first on www.tempertemper.net.

I’ve written about How navigation should work for keyboard users, which includes a healthy dollop of instructions for making screen reader users’ experiences decent too.

I talked about using aria-label to differentiate each <nav> group, but I didn’t really mention how to write your labels. Here’s the example I used:

<nav aria-label="Primary">
    <ul>
        <li><a href="/home">Home</a></li>
        <li><a href="/about">About</a></li>
        <li><a href="/contact">Contact</a></li>
    </ul>
</nav>

Just “Primary”. Doesn’t look like much, but it’s enough. You see, screen reader software announces three things:

• The role of the element
• The name of the element
• The state of the element, if applicable

We’re not concerned with the state in this example (if there was a sub-navigation with a button that triggered it, it’d have a state depending on whether it was opened and closed); here we’re interested in the role and the name.

The role is gleaned from the <nav> element, which has an implicit role="navigation". This lets screen reader users know they’ve arrived at “navigation”.

The name is the accessible name of the element, conveyed by the aria-label attribute: “Primary”. This might be “Secondary” for another navigation group, or something like “Social”, depending on the purpose.

So screen reader software is going to announce something along the lines of “Navigation, Primary” or “Primary navigation landmark”.

And now to the reason I wrote this post: including the word “navigation” in your <nav> labels. There’s no need. If we did, we’d hear something like “Navigation, Primary navigation”. Not the end of the world, but unnecessarily repetitive for screen reader users.

The article There’s no need to include ‘navigation’ in your navigation labels appeared first on www.tempertemper.net.

We often end up in a position where we haven’t considered accessibility, so all that functionality has to be added retrospectively which means:

• the project cost ends up much higher
• legal action has been a real possibility
• the job was only part-done
• a lot of people will have been excluded

That common misconception

The way I use the web and apps is pretty common:

• Touch on my phone
• Mouse or trackpad on my laptop

There’s the keyboard on my laptop too, of course, that I use to type into text boxes. And that’s how the majority of people negotiate their devices.

But that’s not the only way. People use all sorts of different, as the Web Content Accessibility Guidelines (WCAG) calls them, input modalities. In fact, even from my own perspective, mouse/trackpad and touch is only superficially how I get around: I make very heavy use of my keyboard beyond typing text.

How I use the keyboard

I love efficient workflows, and using the keyboard on my laptop plays a huge part in speeding things up.

Web page navigation

If I’m filling out a form on a web page, rather than take my fingers off the keys and onto my trackpad or mouse to move from field to field, I tend to fly through using ⇥ (Tab). I’ll keep my fingers over the keys to check/uncheck checkboxes and press in-form buttons using Space, and I usually try to submit a form using ⏎ (Return/Enter) while still focused on a field, since it’s quicker than tabbing to and pressing the Submit button.

For general browsing, I like to use Space to scroll the page down by a viewport’s-height. I also have a habit of using the ⇥ key to move focus to links or buttons, lazily priming my focus with the mouse/trackpad and tabbing around from there, and I’ll happily arrow around tabs and other button groups.

Note: if you’re a Safari-on-Mac user and want to make more use of the keyboard there’s a bit of config you have to set first.

App and operating system navigation

Regardless of whether I’m typing or clicking around, my left hand is always on my keyboard, as it makes getting around my operating system much quicker; for example, I:

• make heavy use of ⌘ (Command) + ⇥ to switch from app to app
• close windows with ⌘ + w
• open tabs with ⌘ + t
• go to the next or previous tab with ⌃ (Control) + ⇥ or ⌃ + ⇧ (Shift) + ⇥
• cycle through windows with ⌘ + `
• quit an app with ⌘ + q
• press ⏎ to confirm a dialog

You get the idea.

And an uncommon set-up

Every laptop or desktop computer comes equipped with a keyboard, and keyboards are getting more and more common on iPads, but not on phones, surely?

You might find this bizarre, but my keyboard usage extends to my iPhone too, where I sometimes hook a Bluetooth keyboard up to my phone.

Hurdles

Being a hybrid mouse/trackpad and keyboard user, I get a bit of an insight into some of the issues keyboard-only users encounter. Those hurdles irritate me as they break my flow and force me to use a mouse-based workaround, but there’s an extra level of frustration in knowing these are hurdles some people simply can’t get past.

But that’s not the full picture. People use digital products in all sorts of ways, and we’ve only just scratched the surface.

The wider perspective

I love this micro-site on how 100 people who use your website might break down; there are people in that list whose primary input modality might be:

• keyboard-only
• screen reader
• speech recognition software

Or any number of other methods, like a switch device, eye tracking, or head-wand. The point is, as my late father-in-law used to say:

El mundo es plural

Which very roughly translates from Spanish as “Everybody is different”.

Designing and building accessible software means continually questioning your own habits and assumptions. No single way of interacting with technology is universal.

The article Designing and building from our own worldview appeared first on www.tempertemper.net.

What a designer calls something should not differ from what a developer calls it, and the easiest way to ensure this consistency is to use the terminology defined by the super smart people who wrote HTML and ARIA.

The HTML Working Group, HTML Living Standard, and ARIA Working Group spend months and years carefully defining new features (although these groups are not infallible, as the Incomplete List of Mistakes in the Design of CSS from the CSS Working Group proves).

Three particular terms I often hear being used interchangeably are ‘header’, ‘heading’, and ‘title’; I even catch myself doing it sometimes! Let’s have a look how they can be confused.

Header versus heading

I recently wrote about whether headings should be in the header, so let’s start with those two terms. MDN Docs says the header:

represents introductory content, typically a group of introductory or navigational aids.

So that’s the header strip at the top of a page. Logo, strapline, navigation, login; that kind of thing.

Headings, on the other hand, are the <h1> to <h6> elements, which are used to create the document’s ‘outline’. These can be found all over the page, not just at the start.

You’d be forgiven for referring to the <h1> as the ‘header’, since that is usually at the top of the page. They also both start with ‘head’. But they are two very distinct elements, and careful naming here will prevent any crossed wires.

Title versus heading

It’s a very similar story for ‘title’ and ‘heading’, where people often refer to the <h1> as the title. Going back to MDN Docs and their description of the <title> element:

The <title> HTML element defines the document’s title that is shown in a browser’s title bar or a page’s tab

It’s metadata that isn’t output to the page itself. It’s what you see in the browser tab for each web page, it appears in your browsing history, and search engines use it as the heading for a page in their results. The page title is also the first thing a screen reader user will hear when they arrive on a new page.

The main page heading is not, of course, the page title, but the content of the <title> element probably matches the <h1> pretty closely. HMRC have some really nice guidance on the makeup of a page title:

The page title can have up to 4 items separated by dashes. They are:

• the same <h1> as the page
• section name, which you should only include if the service has more than one section
• service name
• GOV.UK

So the main heading content is probably the first part of the page title, but they have very different uses. The <h1> describes the content on the page, where the <title> should do this as well as giving details on things like the section the page is in, the product it belongs to, and business name itself.

Title versus header

This is just here for completeness, but I don’t think there’s any need to talk about using title and header interchangeably as I’ve never seen those terms confused.

Why we mix them up

We muddle these terms for lots of reasons: overlapping meanings in plain English, historical habits in teams, and the blurred line between visual layout and technical specifications.

For me, the reason I sometimes find myself referring to the page heading as the header or title is that ‘header’ and ‘title’ are much quicker to say, where ‘heading’ needs a bit of extra definition: ‘page heading’, ‘main heading’, or maybe even ‘heading level 1’ or ‘h1’.

Hopefully that clarifies what each of the three are and, like me, you can catch yourself quickly if you use the wrong terminology, preventing misunderstandings within your team.

The article Headers, headings, and titles appeared first on www.tempertemper.net.

But I haven’t used it for anything serious like work for a long time. For the last five years I’ve instead relied on work laptops, but now that I’m self employed again I found myself on Apple’s website, weighing up the pros and cons of various machines.

Form factor

First up, it was always going to be a MacBook: I have a Studio Display on the standing desk in my home office which I normally work from, but I’m writing this from the dining room table, and I often work from a coffee shop or shared workspace.

Because I like to be mobile, I also wanted the smaller size (13 inches for the Air, 14 for the Pro) as I’ve had a larger laptop in the past (a 16 inch Pro) and it was heavy, too big for train and aeroplane tray tables, and I never really felt like I needed that extra screen space.

Pro or Air

So the next question was: Pro or Air. Aside from my very first Mac (which I’ll tell you about later), I’ve always used Pros, but the M-series Airs are pretty hard to ignore.

In terms of what I do, there’s not much that’s super intensive. The only thing that ever set off the fans on my last work machine (a MacBook Pro with M2 Pro chip) was batch image compression, and that usually just meant a quick tea break until it was finished. The Airs don’t have fans, which means they slow down instead, but I figured I could deal with that throttling on the odd occasion I asked a lot of it. The Air was very much in contention.

Price

The first thing I did was price each machine up:

• A top-spec M4 Air with 32GB RAM, 512GB storage, 10-core CPU, 10-core GPU, and 16-core Neural Engine came out at £1,599
• An equivalent spec M4 Pro came out at £2,000, but the Pros can have Nano-texture displays, which I’d regret not adding, so make it £2,149

That’s a £550 difference, so what would I get for that, aside from the Nano-texture:

• 1 inch bigger screen
• A slightly nicer display
• An SD card slot
• An HDMI port
• USB-C ports on both sides of the laptop

Screen

The screen size and quality didn’t bother me at all. Just the Nano-texture; as tempting as it was, I figured: it’s a laptop; I can move it slightly or shift position if any glare is bothering me.

Ports

I have loads of dongles from the years using my 2017 MacBook, which only had USB-C ports; I spent hundreds of pounds on them. So on the rare occasion where I ever want to plug an SD card in, I can use the dongle.

On the HDMI front, every time I’ve needed to connect to an external display in recent years, there has been a USB-C option. For projectors, HDMI is still around, but I have a dongle!

My biggest issue with my M2 Pro was connecting to my Studio Display. My Thunderbolt cable dangled down on the right side of the laptop, and every time I went to plug in I’d find the SD card slot first. Every. Single. Time. To find the USB-C port, I’d have to bend down under the desk to visually identify it. I wouldn’t miss that SD slot, even if it meant I didn’t have any ports at all on the right side.

Colours

My first Mac was a white polycarbonate model back in, I think, early 2009. They had discontinued the black version the year before and, while I liked my white one a lot, I would have been all over the black one.

Just like with my phones, I’ve always chosen the darkest model which was, until very recently, Space Grey.

The Pros now come in Space Black, and the Airs in Midnight. Both are nice, but Midnight is darker and a more interesting colour. More points for the Air.

Size

Although the 14 inch Pro isn’t large, per se, it’s thicker than the previous Pro model. The new Airs are around the same thickness as my 2017 Pro, and slightly smaller corner-to-corner, so the Air edges the Pro here yet again.

Power

The Air maxed out at the specifications I listed above (although I could have got a bigger hard drive, I suppose), but the Pro has much, much more headroom. It can be beefed up to around the £5k mark, but that’s way beyond anything I’d ever need. But would the maxed-out Air specs be enough?

Can you guess what I bought?

The maxed-out Air felt like it’d be fast enough. I bought it during my notice period, so I still had my decent-spec M2 machine for some side-by-side comparisons. The Air was miles faster, which I hadn’t anticipated.

Paying over £500 for a Pro just for the Nano-texture display would have been a step too far, especially with all the other little up-sides of the Air.

I’m very happy with my new MacBook Air.

The article A new MacBook for a new chapter appeared first on www.tempertemper.net.

1. Top-down
2. Bottom-up

Both are important, but one is vital.

Top-down approach

Getting buy-in and agreement from the top sounds like the easiest approach since there are far fewer people ‘up there’ in the most senior levels of company leadership (executives, EVPs).

You may be lucky and have a strong ally at board level, but if not it is very, very tough. Reaching them through layers of middle management and getting past gatekeepers is a job, and once you have their attention, their time and patience are limited. They respond well to numbers and clear risk, but this is not always easy, especially in the UK and Europe where example landmark court cases are few and far between.

It takes time and tactics to work on executives, especially in larger organisations; particularly now, with AI dominating executive priorities.

Bottom-up approach

While you’re working on the execs, your day-to-day focus should be on the people ‘on the ground’ who are doing the actual designing and building.

This pool of people is much, much bigger so the number of people with enthusiasm for accessibility will be high. Of course each person’s ‘clout’ is less than those at the top but there is strength in numbers.

One quote that has always stayed with me is from Mike Monteiro in his talk How Designers Destroyed the World:

Every time you make a conscious choice … rather than just letting things happen or accepting what is handed to you by others … you are fulfilling your responsibility

If you don’t think you’ve got the power to make your product more accessible, channel your inner Mike Monteiro and know you can make a difference:

• Researchers can push for a more representative, inclusive panel of users to test with
• Designers can consider the components and patterns they reach for from a different perspective to their own
• Developers can really dig into HTML and ARIA to ensure they’re writing accessible code, as well as get a feel for keyboard-only usage and screen reader software
• Testers can put pressure on their product owner to fix accessibility issues before considering work ‘done’, and for issues found in existing UI, raise bugs and push to get them fixed

Enthusiasm, advocacy, and knowledge sharing gradually spread upwards through product owners and product managers, until senior management has no option but to fall in line with what’s happening on the front lines.

Buy-in from the top makes things easier, but isn’t a prerequisite for building accessible digital products. The people who do are the ones that make the difference.

The article Focus on the people that make things happen appeared first on www.tempertemper.net.

Where other constraints in product design, like security, are seen as non-negotiables, accessibility is often overlooked as an inconvenient nice-to-have. It often comes as a shock to product managers when the penny drops that accessibility is a legal requirement. Not only have they been exposing their product to huge risk, but they now have to re-do a lot of work, sometimes having to put feature development on hold.

The legal landscape is difficult to wrap your head around so, like my deliberately over-simplified breakdown of the Web Content Accessibility Guidelines (WCAG), here’s how accessibility is covered by the law.

Note: I’m not a lawyer, and this is surface-level stuff intended to give you a feel for how it all slots together.

Lots of laws

There are countless laws that govern private sector digital accessibility across the world. Here are the heavy-hitters that I encounter regularly in my day-to-day work:

• European Accessibility Act (EAA)
• Individual EU state employment law
• Equality Act 2010 (United Kingdom)
• Americans with Disabilities Act (ADA)

European Accessibility Act (EAA)

The EAA is the new kid on the block, having taken effect on the 28th of June 2025. Some key points:

• Products already on the market on that date have until 2030 to comply
• It applies to any business that sells into the EU, whether they’re in an EU state or not
• It only applies to websites and apps that are for ‘consumers’, not those intended for business use
• ‘Microenterprises’, defined in Article 3 (23), are exempt

Individual EU state employment law

That last point in the EAA isn’t quite the get-out-of-jail-free card it seems, as business to business (B2B) software is usually covered in legislation on equal opportunity employment in individual EU states, for example:

• Germany’s Sozialgesetzbuch IX, §164
• France’s Code du travail, Article L5213-6
• Spain’s Real Decreto Legislativo 1/2013, Artículo 7
• Italy’s Decreto Legislativo 151/2015, Legge 68

Equality Act 2010 (United Kingdom)

I live in the UK where we’ve had the Equality Act since 2010. It requires organisations to make sure that their services, including websites, mobile apps, and other digital platforms, are accessible to people with disabilities. Section 20 (3) says:

Where a provision, criterion or practice … puts a disabled person at a substantial disadvantage … in comparison with persons who are not disabled, [the duty is] to take such steps as it is reasonable to have to take to avoid the disadvantage.

It doesn’t make a distinction between B2B and direct to consumer (D2C), so if you’re getting in the way of disabled people doing what they need to do using the software you produce, you’re liable.

Americans with Disabilities Act (ADA)

Like the UK’s Equality Act, the ADA covers both D2C and B2B. It has been around since 1990, which pre-dates the internet, but there have been lots of lawsuits relating to websites and apps in the intervening decades.

Here’s what it says about D2C products in Title III, 42 U.S. Code § 12182(a):

No individual shall be discriminated against on the basis of disability in the full and equal enjoyment of the goods, services, facilities, privileges, advantages, or accommodations of any place of public accommodation.

And in Title I, 42 U.S.C. § 12112(a) the ADA covers employee discrimination. This means that digital products people use at work must be accessible:

No covered entity shall discriminate against a qualified individual on the basis of disability in regard … terms, conditions, and privileges of employment.

The public sector

An honourable mention for the public sector, which tends to have separate laws to govern its accessibility, as you’ll definitely have heard of some of these:

• Section 508 in the US
• The Public Sector Bodies Accessibility Regulations 2018 in the UK
• Directive (EU) 2016/2102

But if you’re not a government organisation, you’ll be more interested in complying with the EAA, ADA, etc.

You can be sued!

So accessibility is the law, but who has actually been sued!? Well, it turns out, lots of companies; here are some high profile examples from the United States where thousands of accessibility lawsuits are filed every year:

• Target (2006); this was the first major web accessibility lawsuit and defined a website as a “place of public accommodation”
• Domino’s Pizza (2019); the Supreme Court denied review, which reinforced the 2006 application of the ADA to digital services
• Netflix (2012); the first online-only product to be held accountable

In the UK and Europe, court cases are culturally much less common; the very real threat of legal action is usually avoided as companies are put under pressure by bodies like the RNIB and usually fix issues before being dragged through the courts in a case they are likely to lose.

How to comply

If your product is in a tricky spot, accessibility-wise, you could well be in for a lot of bad PR and legal action; how do you put things right?

Meeting WCAG version 2.2 level AA is a solid baseline for accessibility in the UK and US. In Europe, EN 301 549 has long been the standard, and the good news is that it’s pretty much just WCAG with a few extras, such as ensuring operating systems (like Dark Mode, and Reduce Motion) are respected.

But meeting WCAG/EN 301 549 may still not be enough to avoid legal trouble. WCAG is notoriously open to interpretation and even an objectively conformant website or app can still create barriers; for example, through confusing user journeys.

WCAG is a great first milestone on the way towards accessibility, but a culture of accessible product design and development is the best way to avoid legal issues.

The article Making sense of accessibility and the law appeared first on www.tempertemper.net.

You might be in a similar position. Maybe your product integrates into a larger software ecosystem and your contract with that company says you must be compliant with, or making progress towards, a certain level of accessibility.

The measure most organisations use is the Web Content Accessibility Guidelines (WCAG) version 2.1, level AA; hit this and you have a solid baseline accessibility.

WCAG conformance can be open to interpretation

There are only a handful of rules (WCAG calls them ‘success criteria’, or SCs) that you can measure with a clear ‘yes’ or ‘no’. The overwhelming majority are woolly, grey, and open to interpretation.

Think of an SC and I bet there’s some wiggle room on what could be considered a pass or fail:

• 1.3.1 Info and Relationships? Yep.
• 2.4.6 Headings and Labels? Absolutely.
• 3.2.1 On Focus? You betcha.

Even relatively straightforward SCs like 1.1.1 Non-text Content and 2.4.3 Focus Order, can sometimes be argued one way or the other.

Some things come down to opinion

Granted, most things are still an obvious pass or fail, and the grey areas are often narrow, but there’s a danger there. Let’s say you audit your product and there’s a borderline issue where you could go either way; let’s say you’re feeling permissive, and you give it a ‘pass’.

There will come a time when you need to validate you and your team’s hard work with an objective third party accessibility audit. But it might be that their auditors are stricter, and could view that same issue you passed as a marginal fail.

The benefits of a stricter approach

The good news is that having stricter approach to those ‘is it/isn’t it’ issues has a good number of benefits.

Fewer awkward conversations

I don’t mind a difficult conversation, but I don’t relish them. I want to avoid a situation where I might have to defend my position where I’ve been lenient and a third party auditor hasn’t.

The external auditor has no skin in the game, where my colleagues and I could be seen to have, so the perception is that of course we’d go easy on ourselves. Stakeholders may then wonder what else we’ve been happy to let slip through, which erodes their confidence and the internal accessibility team’s credibility.

Confidence

Speaking of confidence, letting fewer grey-area issues through means you can be confident in your work, regardless of how strict a third party auditor is. No need to fret when it comes to outside scrutiny.

A deeper understanding

When the line is drawn on the stricter side, it also means the conversation with designers and developers goes deeper, which enriches their understanding of accessibility and the various approaches they might take to overcome a potential issue for users.

Better results for users

And, of course, having a stricter position on internal accessibility has the happy effect of making the product that little bit easier for disabled people to use.

WCAG has its (many!) problems, but it’s the standard measure of accessibility. So when we encounter those areas where it’s open to interpretation, there are so many reasons why it’s better to err on the side of caution to ensure compliance when third party audits become part of the process.

The article Erring on the side of caution appeared first on www.tempertemper.net.

I love software design, and Apple do it pretty well; I also spend a lot of time using their software, whether on my wrist, in my hand, on my lap, or desk.

Apple Intelligence

It started with a blink-and-you’ll-miss-it explanation for the headline AI features from last year’s keynote that they didn’t deliver, citing their high quality assurance bar as the reason. Fair enough, I suppose, but it’s not like Apple to announce something that they know might not ship.

There was a bit more AI at this year’s event, with a nice Visual Intelligence feature via the screenshots. I’m still not all that blown away by the whole AI thing, but it’s coming in useful here and there. Maybe in time I’ll wonder how I managed without it, but that’s years off.

Liquid Glass

The headline news was the new visual design language, Liquid Glass, which looks lovely but gives me iOS 7 vibes, in terms of its accessibility, particularly from a contrast point of view with all those translucent backgrounds. I’m sure I’ll dig into that when I get the chance.

Spotlight

A visual refresh is great, but it’s new and improved features that are the most useful; the feature that jumped out to me was Spotlight on macOS.

I use spotlight as my app launcher, rather than the Dock, and the extra power it’s getting will be welcome:

• Quick-launch looks great, so I can carry out an action like adding a to-do list item to Reminders by typing a, r (‘add reminder’)
• It also allows you to do a bunch of things directly inside Spotlight, like typing out the reminder you’ve just quick-launched, rather than going to the Reminders app itself; a bit like Siri, only I don’t have to worry about it constantly misinterpreting my Scottish accent
• Clipboard History looks perfect for me! I use Pastebot for that at the moment, but Pastebot’s other features are wasted on me so I’ll be fine with Clipboard History inside Spotlight

Juicy but not of benefit to me

The changes to iPadOS are probably the most consequential of all, but only for iPad users, and I’m not one. Introducing windows brings it much closer to the Mac experience and, while I’d be interested to try it out, I often need deeper control using things like Terminal to do the work I do, so iPad would never be much more than a writing and scribbling device for me.

Features without fanfare

There are also a handful nice features sneaking in too, which they didn’t speak about but showed on a quick slide:

• Select partial text in a bubble in Messages (finally!)
• Custom snooze length for alarms (not just 9 minutes anymore)
• Export notes to Markdown, which gives me yet another reason to double down on using the Notes app

What’s missing

It has got to the point where there’s not much I’m really desperate for in the way of features across the Apple ecosystem. If you really pressed me, I would have liked draft messages to sync across devices. Slack does that: start writing on your phone, pick it up on your Mac (or vice versa). Only the other day I found a month-old, half-written message on my Mac that I would have noticed and sent had it had it appeared on my iPhone. But I’m not pining for that.

The odd thing I never knew I wanted might appear, as with iPhone Mirroring last year, but in general all I want year-on-year is refinement.

The article WWDC 2025 roundup appeared first on www.tempertemper.net.

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

What that’s saying is that if we use colour on its own to convey meaning, we’re not going to meet 1.4.1. That’s not to say we can’t use colour to convey meaning at all; we just need to have an additional affordance; maybe add some text, maybe use an icon, maybe something else.

But there is an exception where colour on its own can be used to convey meaning. And, annoyingly, it’s buried in WCAG’s ‘Understanding’ piece for 1.4.1:

If content is conveyed through the use of colors that differ not only in their hue, but that also have a significant difference in lightness, then this counts as an additional visual distinction, as long as the difference in relative luminance between the colors leads to a contrast ratio of 3:1 or greater.

My first issue with this is that I really don’t think the accompanying Understanding documents are the place to introduce caveats; that should all be done in the main WCAG document.

Now that that’s off my chest, let’s have a look at what it’s saying in plain English. If the contrast ratio of the colour we’re using to convey meaning is high enough, and we don’t cause any knock-on 1.4.3 Contrast (Minimum) or 1.4.11 Non-text Contrast issues, it’s okay not to have any extra affordances.

So to my second issue: this, like many other WCAG exceptions, encourages designers to get lazy; just up the contrast a bit to 3:1 and we can use colour on its own to convey important information.

We should be aiming to make our digital products as accessible as we can and just enough doesn’t feel right at all.

The article Colour alone can be used to convey meaning, and I don’t like it! appeared first on www.tempertemper.net.

The thing about a table is, it’s rigid; necessarily so. All that information needs to be exactly where it is in that two-dimensional grid in order for the table to be useful for things like:

• Comparing data
• Finding patterns
• Looking for relationships

But that necessary rigidity comes at a cost; it makes things a bit awkward on small screens.

Note: it’s easiest to think of viewport constraints in terms of small screens, but it could also be a larger laptop or desktop computer where the the browser zoom has been increased significantly, causing the content to take up more space within its container.

At screen sizes where the table is wider than the available space, it’s going to need to scroll horizontally, which can be an awkward experience.

1.4.10 Reflow

First let’s see what the rulebook has to say about content that causes scrolling in two directions. The Web Content Accessibility Guidelines (WCAG)'s Reflow says this:

Content can be presented without … requiring scrolling in two dimensions for … Vertical scrolling content at a width equivalent to 320 CSS pixels.

Websites are usually scrollable vertically (up and down), and what this is saying is that on small screens nothing should scroll horizontally as well. So content should wrap and ‘reflow’ in order to fit whatever screen size it’s being viewed on.

It then goes on to say:

Except for parts of the content which require two-dimensional layout for usage or meaning.

Fair enough; there are going to be some situations where the content can’t reflow and still make sense, and it goes on to provide a bunch of specific exceptions in Note 2:

Examples of content which requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content.

So WCAG is okay with data tables scrolling horizontally. This makes sense, since the point of a table is for the data to be relational and comparative.

That word ‘data’

Notice the wording: not “tables”; “data tables”. Let’s look at some definitions of ‘data’.

Google describes data as:

facts and statistics collected together for reference or analysis.

Miriam-Webster has this to say:

factual information (such as measurements or statistics) used as a basis for reasoning, discussion, or calculation

Cambridge Dictionary talks about data in terms of:

information, especially facts or numbers, collected to be examined and considered and used to help decision-making

So WCAG’s not saying you can throw any old content in a table and it’s fine; it has to be data.

Using lists instead, sometimes

So if tables aren’t always the right pattern to use, how might we use lists instead?

Description lists

As I mention in Accessible responsive tables:

One approach to tables that work on all sorts of screen sizes is to reformat the table on smaller screens. Essentially, you take each table row and repurpose it as a sort of <dl>, visually, where each row is presented as a series of keys (each table header) and a values (the value under the header).

I think my main issue with this approach is that it’s not mobile first. If a <dl> (description list) approach is the right approach on small screens, it’s probably the right approach on larger screens too.

Description lists offer a key/value structure. One key, one or more values for that key. So if you were listing the instruments each of The Beatles played in their early years, the markup might look like this:

<h1>Instruments The Beatles played in their early years</h1>
<dl>
    <dt>John Lennon</dt>
        <dd>Rhythm guitar</dd>
        <dd>Harmonica</dd>
    <dt>Paul McCartney</dt>
        <dd>Bass guitar</dd>
    <dt>George Harrison</dt>
        <dd>Lead guitar</dd>
    <dt>Ringo Starr</dt>
        <dd>Drums</dd>
</dl>

This could be marked up as a table, but it works fine as a list, so a list is probably the right call here, since it offers more flexibility.

Unordered/ordered lists

If you need more complexity in each list item, an unordered or ordered list is worth considering.

Here’s a list with facts about The Beatles:

<h1>Beatles facts</h1>
<ul>
    <li>
        <h2>John Lennon</h2>
        <p>John was the founding member of and a lead vocalist in The Beatles.</p>
        <dl>
            <dt>Instruments played</dt>
                <dd>Rhythm guitar</dd>
                <dd>Harmonica</dd>
                <dd>Piano</dd>
            <dt>Place of birth</dt>
                <dd>Liverpool</dd>
            <dt>Date of birth</dt>
                <dd>09/10/1940</dd>
        </dl>
        <p><a href="https://en.wikipedia.org/wiki/John_Lennon">Read more about John on Wikipedia</a>.</p>
    </li>
    <!-- List items for the remaining three Beatles -->
</ul>

Again, this could be presented as a table, but it’s not central that each bit of information is displayed relative to the others.

We can use CSS Grid and Subgrid to make each bit of data align with its equivalent data where space allows, which kind-of offers a table-ish visual experience, but that layout:

• is not vital to the understanding of the data as a whole
• would be more for visual tidiness

The question to ask yourself

So, the question you should always ask yourself if you’re considering reaching for a table to present your content is: could the content also be presented in a list?

If the answer to this is ‘no’, then of course a table is the right element to use. If the answer is ‘yes’, in other words it could be a list or a table, then a list is probably the safest, most flexible pattern to reach for.

The article Are you sure that table isn’t a list? appeared first on www.tempertemper.net.

But I care because I use it when testing the accessibility of web pages. If I click somewhere and then press ⇥ (Tab), keyboard focus is placed on the next interactive element (link, form field, etc.) after where I clicked.

Focus start position

Let’s start at the start.

If a keyboard user presses ⇥ once a page has loaded, focus is placed on the first interactive element on the page, often a skip link. A screen reader user will hear the first bit of content on the page (again, probably/hopefully a skip link).

This suggests the page itself has focus before you move a muscle; this is your focus start position.

It’s invisible

Unlike when you focus on interactive elements, that initial focus isn’t visible. That’s okay, as the page itself:

• isn’t interactive
• can’t be re-focused

A visual indicator would be misleading.

Moving focus position elsewhere on the page

Thinking purely about mouse/pointer use, how do we move that initial focus position elsewhere on the page? All you have to do is click somewhere:

• Clicking a link will usually take your focus to a new page, but some links move your focus to a specific part of the page (I’m thinking of those skip links again, but tables of content often do the same thing)
• Clicking a form field is an obvious way to move your focus as the form field you click will get a focus indicator.
• Clicking a button puts focus on that button, which in turn may place focus somewhere else (like a modal)
• Click on pretty much anything else (an image, or a word in a block of text) it’ll get that same invisible focus that the page itself had

The last example is the one we’re most interested in here, and it’s the one I was struggling to name. I asked around and I very much like ‘focus priming’.

How to prime focus

If I want to check if something works for a screen reader user or keyboard-only user, I prime my focus by clicking my mouse pointer next to the thing I want to test.

I could use a skip link, or navigate down the page using something like my screen reader’s ‘go to next heading’ shortcut, but it’s often quicker to prime my focus using the mouse first.

Using the keyboard

Here’s how to prime focus when testing something for keyboard-only use:

1. Click on some text just before the interactive element you want to tab to
2. Press ⇥ to move focus onto the element

Sometimes it’s necessary to tab backwards onto an element, in which case do the opposite: click just after the button/link/form field you want to give focus to, then press ⇧ (Shift) + ⇥.

Using a screen reader

To test for screen reader users, we’re not going to use the tab key as it’s not just interactive elements we’re interested it; it could be a list, heading, or any other piece of static content.

That aside, it’s exactly the same principle:

1. Prime focus by clicking just before the element you want to test
2. Move through the content to element you want to test (for example VO + →)

And the same if you want to test moving back to some content: prime focus just after the content and read back through the interface.

So now we’ve know what to call it!

Big thanks to Patrick and James for the what-do-we-call-it suggestions. Neither term clashes with already understood ideas or terminology around more obvious focus placement; nor do they require any extra explanation, as they describe both the default focus position and the act of placing focus somewhere else manually perfectly.

The article Focus priming appeared first on www.tempertemper.net.

‘Skip links’ are a great way for keyboard-only users to move their focus past the header and navigation of a web page, directly to the main content area so they can begin interacting with the page.

This is so important that the Web Content Accessibility Guidelines (WCAG) contains a rule called 2.4.1 Bypass Blocks, which says:

A mechanism is available to bypass blocks of content that are repeated on multiple web pages.

Why is this so important?

Imagine there’s an interesting looking link in the opening paragraph of a blog post:

• A mouse/trackpad user only has to move their cursor from wherever it’s currently resting to the link
• A touch-screen user would just tap the link
• A speech recognition software user would say the command to ‘click’ the link
• A sighted or partially sighted screen reader user could move their cursor to the main heading of the page with a quick keyboard shortcut, then jump to the link
• A blind screen reader user wouldn’t not know the link was there on page load, but they will quickly discover it after jumping to the main heading and reading through the first paragraph of content

But it’s not so easy for a keyboard-only user; especially when there are a lot of navigation items, even multiple blocks of navigation, to tab past.

• Amazon’s homepage currently has 44 tab stops before the main page content
• MDN Docs has 38 in the main header, plus any breadcrumb navigation, a language switcher, links to related articles (sometimes over 100), and an outline of the article
• Wikipedia has 18 tab stops before the article-specific navigation
• GitHub has 11
• Even the relatively navigation-light GOV.UK can have up to 6 or so, depending on the page

Keyboard-only users are often keyboard-only users because they have a motor impairment that prevents them using a mouse; this often means they experience fatigue quickly. Repeatedly pressing the tab key before getting to the main chunk of content can be a lot of work, particularly when this would have to be done on every page. Luckily, all of the examples I list above have a skip link of some sort, meaning it’s a single ⇥ press to show and focus the skip link, then ⏎ (Return) to follow it.

How to do it

Skip links are great. And they’re really easy to implement too, requiring zero JavaScript. First, the HTML:

<header>
    <a href="#main" class="skip-link">
        Skip to main content
    </a>
    <!-- Header and navigation content -->
</header>
<main id="main" tabindex="-1">
    <!-- Page contents -->

No fancy code there:

• A main content container with an id
• A link that goes to that id
• The link has a class, so that we can add CSS to show/hide it
• The <main> element has a tabindex="-1" to to ensure browsers put focus on it reliably

And the CSS?

.skip-link:not(:focus):not(:active) {
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}
main:focus {
  outline: none;
}

This looks a bit more complex (TPGi have a good breakdown of the technique), but all it’s doing is:

• Visually hiding the skip link when it doesn’t have focus
• Showing the skip link when it receives focus
• Preventing the main content container getting a focus outline when the skip link is followed (since a focus indicator would suggest it’s interactive, and it’s not; plus focus can’t be placed back onto it manually so an indicator would be doubly misleading)

That’s it!

The article Skip links: what, why, and how appeared first on www.tempertemper.net.

It’s your job as a web developer to ensure your project works in every browser and for every user — and that can be hard to do.

Yep, yep, and yep.

It’s been part of every web-based project’s workflow for a couple of decades to test across multiple browsers and operating systems. I still shudder when I remember wrestling with Internet Explorer 6 quirks; nowadays (thanks to projects like Interop itself and the https://www.webstandards.org before it) it’s much less time consuming to find and fix cross-browser bugs.

As for the and for every user part, that’s what really caught my attention. It’s my job as an accessibility specialist to make sure that the many products in my remit work, or are on their way to working, for all users.

“All users” includes disabled people, so I do a lot of educating and training to ensure designers, developers, testers, user researchers, project owners, etc., etc., are delivering work that’s as accessible as possible. As Jen Simmons says in the Interop article, it’s hard work.

It’s hard work because it means a change in mindset for product delivery teams, it’s hard work because it means change for existing users of products. But it’s worth it.

The article Ensure your project works in every browser and for every user appeared first on www.tempertemper.net.

General fixed-height weirdness

First up, unless the contents of our iframe makes sense as a fixed canvas (or a canvas with fixed proportions), things are going to get a bit weird for the user. We’ve no idea how much room the content in the iframe will need and therefore no idea how big the iframe should be.

Setting height and width attributes on our iframe when embedding a map makes sense as we’ve configured how the map should be displayed and know how it will appear on our site. For arbitrary page content, however, we don’t know how much space will be taken up.

Since we need to set a height on our container (which will also avoid Cumulative Layout Shift), we’re unlikely to get the dimensions exactly right:

• If the iframe is too big for the content there will be empty space between the end of the content and the end of the iframe
• If, more likely, the iframe is smaller than the content presented inside of it, it will have to scroll independently of the parent page

Keyboard users

Tabbing inconsistencies

The keyboard behaviour of iframes is slightly inconsistent from browser to browser. Most browsers don’t include iframes in the page’s tab index, which makes a pretty seamless experience for keyboard users who would tab from the last interactive element on the parent page before the iframe, to the first interactive element in the iframe.

But Apple’s Safari, when full keyboard access is turned on, includes the iframe in the tab index the first time it is encountered. Subsequent attempts to tab onto the iframe won’t work and it will behave just like Firefox, Chrome, and Chromium-based browsers.

That’s something we’ll have to live with as removing the tab stop with tabindex="-1" causes the browser ignore the iframe and everything inside it, which you really wouldn’t want to do as it would make the iframe completely inaccessible for keyboard-only users.

Evening things up by adding tabindex="0" to the iframe wouldn’t be a great idea as it would add an unexpected tab stop for keyboard users who wouldn’t normally expect one. But the good (?) news is that adding tabindex="0" to an <iframe> element does nothing at all to the default behaviour, regardless of browser.

Scrolling

Aside from it being an odd experience, scrolling the content inside an iframe could present a real accessibility issue for keyboard-only users if there are no interactive elements in the embedded content. If the user can’t tab onto an interactive element in the iframe they can’t enter the embedded document, and if they can enter the document they can’t scroll it.

So there’s some logic to Safari’s decision to add iframes to the page’s tab index as it means embedded content can always be scrolled, at least the first time it receives focus.

Screen reader users

iframes need to have an accessible name (which is done via the title="" attribute) in order to satisfy 4.1.2 Name, Role, Value in the Web Content Accessibility Guidelines (WCAG), since an iframe counts as a ‘user interface component’.

That way, the accessible name of each iframe would be announced to screen reader users before they reached the content in the embedded document. For something like a code example, that makes perfect sense, but for general page content it would:

• potentially confuse screen reader users who wouldn’t expect general page content to be brought in via iframes
• create extra noise for screen reader users
• cause extra work for authors, who would have to design a sensible descriptive name for the iframe

What’s more, iframes aren’t navigated like normal content by all screen reader software. To use Apple’s VoiceOver for macOS as an example, when you reach an iframe you can’t just press on through the content with the VoiceOver key (usually ⌃ (Control) + ⌥ (Option)) and → (right); instead you’re stopped at the iframe itself and have to move ‘into’ it using the VoiceOver key, ⇧ (Shift) + ↓ (down). Clunky.

Control

Aside from all of the usability issues with iframes, the biggest issue for me is one of control. The embedded page within your control? It might belong to another department within your organisation or a different organisation entirely.

Responsiveness

If that organisation is YouTube and the content you’re embedding is a video from their platform, you can be reasonably confident that they’ll do their best to ensure the content they serve will always match the height and width attributes they set on the embed code snippet they provided. It’s in their interests to ensure their content is nicely presented out there on the web, so the video will scale up and down nicely as the iframe changes width across various screen sizes.

But if the content you have embedded changes without the kind of rigorous testing that YouTube are sure to carry out, or a bug is introduced that affects its responsiveness, you risk falling short WCAG’s 1.4.10 Reflow and 1.4.4 Resize Text as the content in the iframe becomes inaccessible for some people.

Bug fixes and maintenance

Even if you’ve got control of the embedded document, that’s two websites to maintain, rather than just one. And if you don’t have full control of the embedded document, you’re at the mercy of the people who are: their project priorities may not be the same as yours, and accessibility might be further down on their list, so you could be waiting a long time for any bugs you raise to be ironed out.

Testing

Quality assurance testing can get trickier too, as handy bookmarklets don’t affect content inside of iframes, and more complex browser-based tools like axe DevTools don’t support testing of documents in iframes.

To sum up

The working title for this post was “iframes? More like cryframes, amirite!?”. In case it isn’t already clear what my advice would be for using iframes to embed arbitrary web content inside other documents: don’t.

The article Using iframes to embed arbitrary content is probably a bad idea appeared first on www.tempertemper.net.

User photos and avatars are informational images. Do use clear and concise alternate text to describe them. Otherwise blind screen reader users won’t have access to the same information as sighted people.

Agreed! So why am I writing this? Well, there is a context in which user avatars should be:

• presented visually
• hidden from assistive technology like screen reader software

Where I work there are lots of lists; some present bank transactions, some payslips, and some present people. Many of those lists of people include their avatar photo, which is a great visual hooks for people glancing through the list. But is it useful to convey the same information to blind screen reader users?

As long as the avatars sit alongside the person’s name and a bunch of other information, all of which is enough to identify the person, I’d say the description of the person is superfluous.

A blind screen reader user should get the same experience as a sighted user: fly through that list to quickly identify each person until they land on the one they’re after. But if they get exactly the same content it could be a worse experience.

So, in this context, I’d use an empty ‘alt’ tag for each image, like this:

<li>
    <img src="martin-underhill.jpg" alt="" />
    <span class="name">Martin Underhill</span>
    <!-- Rest of the information -->
</li>

The alternative would be unnecessary information in our context:

<li>
    <img src="martin-underhill.jpg" alt="A friendly looking man with a bald head, beard, and glasses." />
    <span class="name">Martin Underhill</span>
    <!-- Rest of the information -->
</li>

Of course, as Nicolas says, describe the avatar photos in other places, like each person’s profile page. But, just as an icon that is paired with some text can provide a visual hook only and should be hidden from assistive technology, a user avatar or photo is sometimes only for sighted users.

The article Avatars and alt text appeared first on www.tempertemper.net.

Three years ago I upgraded to an iPhone 13 Mini from an iPhone XS and now it was time to pass my beloved 13 Mini down the chain. I’ve just bought myself a 16 Pro; here’s what I’ve noticed in the upgrade.

Camera

My two-models-ago XS had a nifty 2x zoom lens, which I found myself using a good amount. It was great for getting a better shot of my kids playing and, for some reason (I’m very much not a photographer), I preferred the photos it took.

I loved my 13 Mini. Loved it. But I missed that zoom lens. I was taking photos of my kids playing together on the beach this summer and zoom would have made for some much better snaps.

I did considered the standard 16, with its 2x telephoto, but the 5x lens on the Pro models was too much to resist. And it looks great. All the cameras do!

Camera Control

The Camera Control feels like a nice idea but I initially found it irritating. I would accidentally launch the camera app while doing other things, particularly when adjusting the volume down… My grip on the opposite side of the phone as I squeeze the volume buttons is low, in order to avoid the Side Button which would take a screen shot or lock the phone; low enough to press the Camera Control. This is also not helped by the fact that it’s flush to the side of the phone, rather than slightly raised like all the rets of the buttons.

I’ve circumvented this by requiring a double click to open the camera in Settings → Camera → Camera Control → Double Click.

The problem now is one of software as I have to triple click to open the camera when the phone is locked: once to wake the phone and twice to launch the camera. If the phone is awake, I should be double clicking, but I still end up triple clicking which means I launch the camera and immediately take a photo. Looks like this is being addressed in iOS 18.2 where they’ve added and option to bypass the ‘waking’ bit and launch the camera with a single or double press, depending on your settings, whether it’s awake or not.

Finally, I find the camera control itself really fiddly. The half-press, the double half-press, and the swipe/scroll gestures are just too fiddly. I’d like some way to configure the control in Settings rather than when taking a photo. Or at least limit what accidental swipes can do. It just doesn’t feel well tested.

Action Button

Since getting my first Apple Watch, I’ve always use my phone on silent, preferring a tap on the wrist for notifications, so I haven’t used the Mute Switch in years. The Action Button is a great idea for people like me.

I’ve assigned the Torch to the Action Button, as I use the torch all the time, and it’s now super convenient to access with a long press of the Action Button. I’ve also removed the torch from both Control Centre and my Lock Screen, freeing up space for other utilities.

One small gripe, though, is that the Action Button isn’t quitez far enough away from the volume buttons, so I often press it when I’m fumbling to turn the volume up.

Dynamic Island

I like the Dynamic Island a lot. The design is delightful and it’s a super clever way to lean into the (for now) necessary cut-out to accommodate the front camera and sensors, but I don’t think Apple have got the interaction pattern quite right.

Battery

I was very conscious of my battery with the 13 Mini. It was fine, but it was always in the back of my mind. I had a MagSafe Battery Pack (now unfortunately discontinued) which got frequent use, but it has been passed to my wife alongside the 13 Mini as the 16 Pro lasts all day and more.

Screen

The Always-On feature is taking some getting used to. It’s weird that the screen doesn’t turn off, and I had imagined the wallpaper would be dimmed further than it is when in Always-On. I guess it makes me uneasy because I was was so conscious of the battery in my little 13 Mini, but Apple must know what they’re doing so I’m leaving the feature switched on.

I now have Pro Motion, which is one of those stealth features that makes a huge difference but is something you’ll never notice. The 120 frames per second refresh rate make the phone feel ridiculously smooth and responsive, and it’s only when you go back that you realise how nice it is; like when I was setting up my wife’s on my outgoing 13 Mini.

The screen is also really big too, and the smaller bezels make a difference. Though I’m back to it feeling slightly insecure in hand, as there’s more stretching to reach much of the screen. I’m making good use of Back Tap for Control Centre and Reachability, which has helped.

Case

Apple have stopped doing leather cases, which I understand, but I did love their leather cases. I got one of their silicon cases instead, which is nice but doesn’t slide in and out of my pocket as nicely as the leather case. One perk is that it feels more grippier in hand, offsetting the slightly insecure feeling while reaching around the screen on a much bigger device.

USB-C

This has taken a wee bit of adjusting to. I’ve had to buy a new cable for the car (I need to plug the phone in to use CarPlay) and I decided to go the MagSafe Charger route for miscellaneous charging around the house, since that’s compatible with my wife’s phone too.

Overall, though, it’s probably better than Lightning: faster to charge and easy to pinch a charge when I’m working from my MacBook (I use USB-C to charge as, unlike the MagSafe charger, it can be plugged in on either side of the laptop). Problem is, I’m now finding myself wishing all of my peripherals (mouse, keyboard, etc.) were USB-C too!

Speakers

Not much to say here except the sound quality is really, really good.

Conclusion

I like my 3-ish years upgrade cadence. If I upgraded each year I don’t think I would appreciate the new features quite as much. Plus it would be very expensive! This 16 Pro is an amazing piece of hardware; on balance I prefer the larger size and I’m looking forward to putting the camera through its paces!

The article Upgrading from iPhone 13 mini to 16 Pro appeared first on www.tempertemper.net.

I like that I don’t notice that there’s some inactive space where the cameras/sensors are. The animations they’ve used feel perfect, making it feel almost alive. I like that it offers a visual element to the iPhone’s background activity like playing music or a podcast. But it’s flawed.

There are two ways in interact with the app that’s running in the Dynamic Island:

1. As a widget, up there at the top of the screen
2. In the app itself

You access each of these via the Dynamic Island with either a tap or a long-press. Before you read any more, take a moment to think about which way round this should be.

Me? I would expect a quick tap would open the Dynamic Island so I could interact with it as a widget:

• Pause/play, scrubbing, skip back/forward a track in Music
• Loud speaker, mute, phone down in Phone
• Check who scored in Apple Sports’ Live Activity

So a quick tap would offer a wee bit more functionality or information that you can access with a tap.

A long press should do something weightier, more deliberate, like taking me away from the app I’m currently using and land me on the relevant page of the app that was running in the Dynamic Island.

But it’s the other way round…

A tap on the Dynamic Island opens the app that’s running in there, taking you away from the app you’re currently using. I accidentally do this all the time, thinking I’ll trigger the widget popover…

A long press does that, of course. But how many people will think to long press? It makes the multi-tasking dimension the Dynamic Island brings both less discoverable and more awkward to access.

I’m assuming Apple’s thinking is that, since tapping an app icon on the Home Screen launches the app, the same should happen with the Dynamic Island. But it isn’t an app: it’s the Dynamic Island!

Again, I can see where they’re going with the long press. A long press usually triggers a popover, like a context menu, and the widget is like a popover, overlaying the app beneath it.

The logic of the design language may be right, but it feels wrong.

Let the user access the app’s widget first, then the app itself with a tap of the widget. Two quick taps. Or if you want to bypass the second tap, and therefore the widget, a long press of the Dynamic Island makes sense.

In theory, there’s good news in that this is a software thing, rather than baked into the hardware, and can therefore be changed relatively easily, but the Dynamic Island has been around for three iOS releases so I doubt Apple agree with me.

The article Apple, you’re doing the Dynamic Island wrong appeared first on www.tempertemper.net.

I’ve written about how to get started with VoiceOver on macOS but VoiceOver is an Apple-only screen reader so what if you’re a Windows user?

The good news is you’ve got plenty of options, from the built-in Narrator to the two most widely used screen readers in the world: JAWS and NVDA. Let’s talk about the latter.

Page contents:

Install NVDA

NVDA isn’t built in to Windows, so the first thing you need to do is download the most recent version for free.

When setting up, make sure NVDA doesn’t launch on startup as you’re probably not going to want it running all the time. For when you do want to do some testing with it, it’s a good idea to pin the app to your Taskbar so that it’s easy to fire up whenever needed.

Open your web browser

This bit is much easier than with VoiceOver on Mac since NVDA works with any browser you might have on Windows. GOV.UK recommend testing with Firefox, Chrome, or Edge, but every other browser I can think of is based on the same Chromium engine that Chrome and Edge are built on, so you can test with Opera, Brave, Vivaldi; whatever you like.

Having said that, GOV.UK list only Chrome or Edge as the browsers to test with JAWS, so I like to reserve Chromium browsers for JAWS and use Firefox for my NVDA testing; that way I get as broad a sweep of browsers in my testing as possible.

Configure NVDA

Like with most software you test with, the default settings are pretty much what you want to be testing with since very few users will change them.

But there are a few things I do to make NVDA more useable for me, all of which you’ll find by going to NVDA in the Taskbar’s System Tray.

Prevent automatic reading

First up, take full control. By default, NVDA will read its way through all of the content on the page until you stop it. I turn this off in Preferences → Settings… → Browse Mode → Automatically say all on page load.

Disable mouse tracking

Next, keep things keyboard-only. I don’t like that my focus position is moved to where my mouse cursor is hovering if I accidentally nudge the mouse, so I turn off mouse tracking in Preferences → Settings… → Mouse → Enable mouse tracking.

Enable highlighting

I like to see where my cursor is, so I turn on highlighting, which places a blue rectangle around the element that I’m currently focused on. It can be a wee bit buggy sometimes when the page scrolls but I still prefer it. Activate it in Preferences → Settings… → Vision → Enable Highlighting.

Speech viewer

Finally, I turn Speech viewer on in Tools → Speech viewer, which keeps a text-based log of all of the things NVDA reads out. Great in case I miss something it says, or I want to copy/paste something that it read out.

Navigation commands to get started

Screen reader software can be noisy, so the first thing to know is how to pause it. Like VoiceOver, the Ctrl key will shut NVDA up. Aside from that, you only need a handful of commands to get around:

↓ (down arrow key)

Go to next thing (heading, paragraph, list item, etc.)

↑ (up arrow key)

Go to previous thing (heading, paragraph, list item, etc.)

⏎ (Enter/Return)

Follow a link, press a button, or interact with a form field

Space

Press a button

k

Go to next link (useful for links that appear inside a sentence since, unlike VoiceOver, NVDA doesn’t stop before and after a link)

⇧ (Shift) + k

Go to previous link

h

Go to next heading (most screen reader users use headings to find information on a page)

⇧ + h

Go to previous heading

Something else that will come in useful when navigating the web isn’t an NVDA command, but a keyboard-only shortcut that’s available whether you’re using NVDA or not: go back a page with Alt + ← (left arrow).

Form filling

When you move your NVDA cursor to a form field, it will be read out but, unlike VoiceOver, simply typing will not do anything. In fact, it’ll probably trigger a bunch of NVDA shortcuts that’ll navigate you all over the page, and you’ll end up disoriented.

As mentioned above, to interact with a form field when it has focus, press ⏎ and start typing (or, if you’re on something like a <select>, use default keyboard behaviour to choose an option). When finished, press the Esc key to go back to exit the form field and go back into ‘navigation mode’.

Take your time

NVDA is a powerful tool and there’s loads more to learn, but that should get you started. Screen reader usage is a very different way to use the web for many of us, and can be noisy and disorienting when you’re getting to grips with it. Patience and persistence are the key: find yourself a quiet spot where you can spend an uninterrupted hour with the software and you’ll be well on your way.

Not only will it give you an amazing insight into one of the many ways people use the web, but it may even offer a better understanding underlying HTML/ARIA that makes up a web page. Good luck!

The article Getting started with NVDA appeared first on www.tempertemper.net.

The organisations in question often have that problem where:

• historically, they have not designed and built with accessibility in mind
• their existing user base, therefore, does not include many/any people with disabilities since they have been unable to use the product

When we introduce a change that improves accessibility, there’s often a barrage of negative user feedback that product stakeholders find difficult to ignore. That feedback usually gets to them through unfiltered Customer Satisfaction channels like online surveys, help centre enquiries, and social media, rather than via user testing sessions where a user researcher can separate user wants from user needs.

Problems to overcome

The way I see it, there are two problems to overcome:

1. Users’ natural discomfort with change
2. A homogenous user-base

Users dislike change

Any change you make, regardless of the reason, is going to be met with hostility from users. Much as I hate to link to something by Jakob Nielsen after his irresponsible and damaging comments on AI and accessibility, his video on Users Hate Change hits the nail on the head:

Any time you release a new user interface design, you’ll get complaints. This doesn’t mean that the new design is worse than the old design; it simply means that it’s new, and users don’t like to learn different ways of doing things

A new, accessible design isn’t just likely to be objectively better, it’s often necessary, but the feedback in user testing and via customer service is unlikely to be positive. Users don’t want change, even if they and many others would benefit from it.

All your users look the same

Your user-base is representative of who you’ve been designing for, and if, historically, your digital product team hasn’t considered accessibility you’ve defined ‘done’ as ‘it works for me’. This is because:

• the majority of the working population is non-disabled, so the majority of people who design and build digital products are non-disabled
• Disabled people are less likely to be employed, so product teams employ fewer disabled people than they should
• Disabled people in employment often hide their disabilities, so product teams may unknowingly include disabled people who feel they don’t have a voice

Potential disabled users have been overlooked.

So as you begin to introduce changes that unlock your interface for people that were previously excluded, the feedback from existing users is not only going to be negative, it’s also likely to be unanimous.

Not only is there the natural discomfort with change, they’re also unlikely to see why the changes have been made, as it doesn’t benefit them.

The good news here is that this will change with time as a your user-base becomes more diverse, so the big issue is managing all of this unhappy users in the meantime.

Change management

The aim is to introduce changes with the minimal upset to users, and this can usually be achieved with steady, planned, incremental updates to the user interface (UI). Where this isn’t possible it may be necessary to manage the change with careful, succinct, and dismissible explanation in the UI itself, or an email or social media campaign to inform users of your drive towards accessibility and inclusion.

As our user-base starts to reflect the proportion of disabled people in the general population we can start to really understand what will make our product better; making it easy to distinguish what our users think they want versus what they actually need.

The article User ‘wants’ versus accessibility appeared first on www.tempertemper.net.

That said, all I wanted this year was a stand-alone Passwords app and Automatic transcription in Voice Memos. Actually, that’s not quite true; I added a late request to my WWDC 2024 wish list: Extensions in web apps so that I can get dark mode (via Noir) in my Google Docs web app.

Well, I got the web apps Extensions:

Now you can personalize web apps on Mac with Safari Web Extensions and Content Blockers. Navigate to the web app’s Settings menu to access all your installed Content Blockers and Web Extensions. Any enabled in Safari will be on by default in the web app. Each web app is uniquely customizable, just like Safari profiles.

They also announced a Passwords app, which looks great.

Two out of three isn’t bad, but they usually release more than they announce so I thought to keep digging and… bingo! From Android Authority:

The Voice Memo app in iOS 18 will be able to transcribe recordings, a feature that has been present on Google Pixel devices and various third-party apps for several years.

So it looks like all my wishes have been granted!

What else was interesting?

iOS 18

The updates to the Home Screen are nice: apps can be placed anywhere and app icons get a dark mode.

Tapbacks in Messages are no longer limited to a thumbs-up, heart, and a couple of other reactions; you can now use any emoji to react to a post. Messages can also be scheduled, which will be a good way to avoid missing sending someone a happy birthday message.

tvOS 18

As always, not much here, but Enhance Dialogue, where voices are amplified and background noise is minimised, is a nice accessibility feature.

WatchOS 11

A strange omission on Apple Watch has now been rectified: you can pause your Activity Rings in the Activity app. This allows a weekly rest day, or some time to recover from a niggling injury, all without losing your streaks.

macOS Sequoia

A couple of things specific to macOS look nice.

Window Tiling

Users can stay organized with new ways to arrange windows into a layout that works best for them. When a user drags a window to the edge of the screen, macOS Sequoia automatically suggests a tiled position on their desktop. Users can release their window right into place, quickly arrange tiles side by side, or place them in corners to keep even more apps in view. And new keyboard and menu shortcuts help users organize tiles even faster.

This will be more powerful than my old faithful Divvy. Sorry Divvy!

iPhone Mirroring

You can now use your iPhone entirely within macOS. There are lots of situations when I’m using my Mac, my phone is in my pocket, and it would be awkward to take it out to carry out a quick task; or when I’m at my desk and I’ve got my phone in Standby.

There’s something interesting about all of this device virtualisation Apple are doing: macOS runs inside visionOS too. Maybe one day devices other than Apple Vision will be redundant?

Siri

Improvements to Siri are long overdue. You can now ask follow-on questions, so it’s more of a conversation, where previously it was more like a command line where you speak a self-contained instruction. Let’s just hope Siri will get better at understanding my Scottish accent…

I almost never use Siri in public, so Type to Siri will be useful: Double tap the app switcher bar to activate Siri as a text input, so Siri’s functionality can be used without speaking, and the responses appear in text rather than being spoken aloud.

Apple Intelligence

I’m not entirely sure about this one. All the stuff about creating images and even rewriting text feels a bit gimmicky.

I do like the look of Clean Up in Photos:

identify and remove distracting objects in the background of a photo — without accidentally altering the subject.

Some Safari fixes

Date and time inputs will be fixed for screen reader users:

WebKit for Safari 18 beta on macOS improves accessibility support for date and time input field types. Now <input type="date">, <input type="datetime-local">, and <input type="time"> elements work properly with VoiceOver.

One final interesting titbit from the Accessibility section: They’re removing the erroneous implicit role="banner" when a <header> element is used inside a <main> or sectioning element, so we’ll be able to use the <header> element as intended without confusing screen reader users.

The article WWDC 2024 roundup appeared first on www.tempertemper.net.

The good news in that there are very few keys you need to use:

• ⇥ (Tab key)
• Space
• ⏎ (Return/Enter)
• Esc
• ↑ ↓ ← → (the up, down, left, and right arrow keys)
• ⇧ (Shift)

Note: In this article I’m going to focus on using the keyboard to get around a web page, rather than the whole operating system (which is a bit more complex and can be activated via Settings → Accessibility → Motor → Keyboard → toggle Full keyboard access).

Page contents:

Scrolling

The assumption is that keyboard-only user can see the screen, so how would someone move up and down a web page to read the content?

Space scrolls the viewport down by about a viewport’s height at a time until it reaches the bottom, and ⇧ + Space scrolls it back up; again by a viewport’s height until it reaches the top.

In some browsers the ↓ will nudge the page down slightly, and ↑ will nudge it up again.

You can also jump to the bottom of the page with ⌘ (Command) + ↓ on macOS and the End key on Windows. The opposite is also true: you can scroll back to the top of the page with ⌘ + ↑ on macOS and Home on Windows.

The tab key

As a keyboard-only user the tab key is your friend. It moves focus from one interactive element to another:

• Links
• Buttons
• Form fields
• Other interactive components, such as accessible tables

⇧ + ⇥ moves backwards to the previous interactive element.

Note: by default Safari on macOS only tabs to form fields; you have to activate tabbing to all interactive components.

Once you reach the last interactive element in a web page, pressing ⇥ will circle your focus back to the top of the browser. ⇧ + ⇥ from the first interactive item on a page brings focus to the items in the browser’s chrome (tabs, bookmarks, address bar, etc.).

Following links and pressing buttons

When you are focused on a link, pressing ⏎ follows it; the same with a button.

The Space key can also be used to press a button, although this isn’t the case with links. Pressing space when focus is on a link scrolls the page down rather than following the link.

Interacting with forms

Things get a wee bit more complicated when filling a form in.

Text-based form fields like text <input>s and <textarea>s are pretty straightforward: tab onto the field, type a value, then tab onto the next field.

Checkboxes are even simpler: check/de-check using the Space key.

Radio buttons

Checkboxes can exist individually or as a group (a <fieldset>), but the keyboard behaviour doesn’t change one way or the other. Radios only make sense as a group of two or more and behave differently to a group of checkboxes. Instead of being independent controls (in other words, tab to a checkbox, check it if appropriate, tab to the next, and so on) radio buttons work as a unified whole; here’s how they work:

• Tab onto the radio group; this highlights the first radio item but doesn’t select it
• Press Space to select that first highlighted-but-not-selected radio button
• Press ↓ or → to move to and select the next radio button
• Press ↑ or ← to move to and select the previous radio button
• ⇥ takes you out of the radio group and onto the next interactive element on the page

Tabbing backwards onto a radio group where no items have been selected highlights the last item (without selecting it); tabbing or ⇧-tabbing onto a radio group when an item has already been selected places focus on that item.

Select dropdowns

<select>s behave differently on macOS and Windows. Once you’ve tabbed onto the parent ‘button’, open the menu by pressing Space and close it with Esc. Beyond that, things get interesting:

macOS

On macOS you can also use ↑ or ↓ to open the menu. If an option hasn’t already been selected it will focus on the top option, otherwise it’ll highlight the previously selected option.

Further presses of the ↑ or ↓ keys move focus up and down the options until you hit the last (or come back up to the first) option, at which point it will stop.

Moving from option to option only highlights that option, it doesn’t select it. To select the option you must press Space or ⏎, at which point the menu closes and the value of the parent button changes to the selected option. If you re-open the menu the selected option will have a tick next to it.

Windows

On Windows, instead of pressing Space, you can use any of the arrow keys to change an option:

• ↓ and → move to the next option until you hit the last one, at which point it’ll stop
• ↑ and ← move to the previous option until you hit the first one, where it’ll stop

When doing this, the menu remains closed and the label of the button changes. You can also open the menu first so that you can see the whole list of options; just press Space before using the arrow keys.

The big thing here is that highlighting an option also selects it; these are not separate steps like they are on macOS. This means that Space and ⏎ only have the effect of closing the menu, the same thing as pressing the Esc key.

Moving around items in a group

You’ll encounter other ‘groups’ of things, for example:

• tabs in a tab panel
• buttons in a button toggle
• menu items in a menubar

None of these patterns are native HTML so there’s no ‘default’ behaviour to refer to. There is some commonality though: like a radio group, the group of tabs/buttons/menu items should be a single tab stop, and the arrow keys are the mechanism to move focus from one tab/button/menu item to the next. Each item is essentially a button, so the expected keyboard behaviour would be that each button is pressed in the normal way (⏎ or Space).

The article How to browse the web with the keyboard alone appeared first on www.tempertemper.net.

• Automatic Voice Memos transcription (please!)
• A stand-alone Passwords app

I’ve been using Apple’s built-in password manager for a couple of years now and it has been nothing if not reliable, but every now and then I encounter a hurdle.

Using Shortcuts, I made a fake Passwords app, which comes in handy on iPhone, but on my Mac I launch most apps using Spotlight so I don’t use the fake app on there. What does irk slightly is whenever I’m required to re-log in to a service in Internet Accounts; something like iCloud, my Google account, or an IMAP email account. Because Internet accounts and Passwords both live inside the same app (Settings) I have to:

1. Open Settings → Passwords on a different device
2. Copy the password I need (which puts it in my Universal Clipboard)
3. Paste it into the password field
4. Back on my other device, get the one-time code and either copy/paste it in similar fashion or just type it in

Not a huge deal, but not very slick. Passwords aren’t a setting, so it’s time Apple moved them into their own stand-alone app.

The good news is that Apple might be granting my wish at this year’s WWDC. Fingers crossed!

The article All I want from WWDC 2024 appeared first on www.tempertemper.net.

Why did I use inverted commas? Well, they profess to make a website more accessible, but do little-to-nothing of any real use; in fact, they can actually hinder a disabled user’s experience of a website! Here are some great resources that go into detail on the problems with accessibility overlays:

• Overlay Fact Sheet
• Should I Use An Accessibility Overlay?
• Adrian Roselli’s wealth of information and documentation on overlays
• Do away with overlays
• Why accessibility overlays do not improve site accessibility

Disabled people will likely already be using some kind of mechanism to make their experience accessible:

• browser extensions
• features built into their browser
• operating system accessibility features
• third-party software the runs at the operating system level, such as a screen reader

But let’s imagine a disabled visitor who hasn’t made any of those adjustments and doesn’t have any helpful software running. Are they likely to:

• notice a website’s accessibility overlay icon at all?
• pause their task in hand to find out what the label-less button is for?
• be able to use the overlay in the first place, without the features it offers that they need?
• take time to configure their preferences?
• wonder if their configuration will persist across other websites? (It won’t…)

Accessibility overlays are not for disabled people.

Who are accessibility overlays for?

So if not disabled people, who do accessibility overlays benefit?

There are the overlay companies themselves, of course, who make money every time somebody chooses to use their product. But that probably goes without saying.

Who else? I’m sorry to say it, but those who benefit from accessibility overlays are the people that license and install the overlay software…

I’m going to assume the best in those buyers; that they’re trying to do the best by their users instead of looking for a shortcut to accessibility. So, with the best intentions, non-disabled buyers pay overlay companies for a tool that sounds great:

• Protect yourself from lawsuits!
• Achieve a baseline level of accessibility!
• Give disabled users a better experience!

None of this true. But people can be easily mislead where there’s slick sales patter and a lack of understanding.

Accessibility overlays are for non-disabled people by non-disabled people. The only way to properly address accessibility issues is at the product development level: carefully considered designs and well written code. Adding a single line of JavaScript to your website or app is not the answer.

The article Accessibility overlays are not for disabled people appeared first on www.tempertemper.net.

Where I work there are lots and lots (and lots!) of digital products. All are working hard to achieve a level of accessibility, but the vast majority are not at that baseline WCAG 2.1 AA level of compliance yet.

Last week I was heartened when two separate conversations about two separate products were around the experience of screen reader users, rather than if a screen reader user would actually be able to use the product.

These are the types of accessibility conversations you want to be having!

The article The accessibility conversations you want to be having appeared first on www.tempertemper.net.

Keyboard-only users

A keyboard-only user gets around an interface with only a handful of keys:

• The up and down arrow keys to scroll up and down the page
• ⇥ (Tab) and ⇧ (Shift) + ⇥ to move focus from one interactive element (links, buttons, form fields) to the next
• ⏎ (Return), Space, and the arrow keys to interact with elements when they have focus
• One or two other keys, such as Esc which should close a modal or popover
• They’ll also type freely into text-based form fields

Keyboard-only users only need to interact with the content on the screen, and we can assume that they can see non-interactive content like headings and paragraph text.

Screen reader users

With screen reader users, there’s no guarantee that they can see the contents of the screen, so they’ll use their screen reader to access to any content on the screen, not just interactive stuff like buttons, links, and so on.

If a screen reader user were to use ⇥ to jump from one interactive element to the next they’d miss important content, so they’d use their screen reader software’s navigation shortcut keys to get around instead.

They’d move from one chunk of content to the next, jump from heading to heading to get a feel for the content on the page, skip straight to a particular page landmark like the footer; that kind of thing. Other than filling in form content, they’d be unlikely to use the same keys to negotiate an interface as a keyboard-only user.

Note: That’s not to say that screen reader users will never use the tab key; more that screen reader users will only use the it if they already know exactly what’s on the screen.

Manual testing

This is one to bear in mind if you’re doing any manual accessibility testing. Using the keyboard and using a screen reader should be treated separately:

1. First test using the keyboard like a keyboard-only user
2. Then test with a screen reader using its build-in key commands

The article Screen reader users and the tab key appeared first on www.tempertemper.net.

According to the most recent WebAIM Screen Reader User Survey (from 2021), 79.5% of screen reader users are blind. The remaining 20.5% who are not blind may have low or impaired vision, but some may have perfect vision. Let me explain…

According to the British Dyslexia Association:

Dyslexia is a specific learning difficulty which primarily affects reading and writing skills … Dyslexia is actually about information processing

I know a lot of dyslexic people (around 1 in 10 people is dyslexic) and many of them use:

• simple text-to-speech software like NaturalReader or
• more hardcore screen reader software, such as VoiceOver

This is because listening to content can make it much easier to digest than reading it on the screen; from dyslexic.com:

Those with dyslexia often find that text-to-speech software provides significant support if they struggle with reading or digesting text on the computer screen.

So there you have it! Some screen reader users can see the screen perfectly well; instead of using the software to access content, they use it to process and understand.

The article Not all screen reader users are blind appeared first on www.tempertemper.net.

We had a full rewire, plastering throughout, new flooring, new kitchen and bathroom; the works. It cost a fair amount of money (not to mention effort!) but we’d budgeted for it and, because were able to do it all in one go, it was relatively cost efficient.

Our second and third places were also fixer-uppers but:

• we didn’t have the luxury of renting while we did it
• children were a factor; a toddler with our second place, and a 5 year old and a baby when it came to house number three
• our renovation budget didn’t cover everything, so we had to decide what to do first and let our savings accumulate before moving on to the next job

All this meant we had to tackle each place room by room, so it:

• was more expensive over-all
• took a lot longer than blitzing it all in one go

This is a lot like most (all?) web or native mobile products on their way to being accessible. Rarely do we have the luxury of a full rebuild, and most of the time we do things like:

• Upgrade the underlying technology (or sometimes technologies!)
• Fix accessibility issues in the existing UI (user interface)
• Replace sections of a monolithic product with more manageable microservices

All this while continuing to give our customers those new features that they’re asking for!

Accessibility is expensive if it’s not considered from the outset, and a lot of companies are finding this out the hard way.

The article Accessibility by degrees appeared first on www.tempertemper.net.

Software demands more creative discipline than hardware, because so much discipline is baked into the nature of creating hardware. Hardware instills discipline in people; people must instil discipline into software.

I’d say that accessibility is a great measure of mature, disciplined software production.

Accessibility, unfortunately, isn’t even an after-thought in self-proclaimed ‘move fast and break things’ organisations. They build for one group of users (and they’re not disabled users), and customer support is often the only form of user feedback they get.

The truth of it, though, is that accessibility actually makes it easier to move fast, and there’s no need to break anything! Accessibility:

• narrows down design choices, making the ideation much more time-efficient
• promotes the use of a design system, which streamlines the whole design and development process
• makes it easier for everyone to use an interface or complete a task, removing the need for extra work-arounds for some groups of users
• opens designers up to fresh approaches to meeting user needs
• removes a great deal of the re-work that’s necessary when the accessibility penny finally drops

Twitter, where one of Musk’s first moves was to lay off the entire accessibility team, is an example of a company that’s heading in exactly the wrong direction.

The article Accessibility represents maturity appeared first on www.tempertemper.net.