Like many people, I have been monitoring the creation of WCAG 2.2, the upcoming new version of the Web Content Accessibility Guidelines. Nine new Sucess Criteria are proposed. One particularly worries me: 2.4.11: Focus Appearance.

Focus Appearance builds on two existing WCAG criteria that affect focus indicators: that users can see which element has focus (2.4.7), and that focus styles have sufficient contrast (1.4.11). Focus indication is essential for a wide range of users, including users who browse by keyboard or zoom in. For an introduction to why focus indication matters, see my post on indicating focus.

What's new about 2.4.11 is adds more requirements for what the indicator looks like:

• an element with focus needs to have sufficient contrast with its non-focused state
• an element with focus needs to have sufficient contrast with its surroundings
• the focus indicator needs to either be a solid line (so not dotted or dashed), or have a certain level or thickness (in which it can be dotted or dashed)

It's a clever new criterion, that addresses important user needs that were previously unaddressed. The Working Group clearly put a lot of research and thought into it. This is hard to do, as co-chair Alastair Campbell mentions in a GitHub issue:

what makes a visible focus indicator is not particularly straightforward

This is the crux of why this isn't trivial to solve and I appreciate everyone's efforts on the proposed Success Criterion. I know the text has had revisions and improvements after people have flagged complexity issues. Still, I'm sorry the Success Criterion as it stands now has me worried.

“Focus Appearance” is “at risk” of being removed from the final version of WCAG 2.2. My vote would be to drastically change it (again) or remove it entirely. Firstly, the requirements are complex to apply or teach. Secondly, browsers, OSes or assistive technologies could guarantee focus appearance better (and I feel it would be easier to talk to them than to convince all of the world's web developers).

Why I hesitate about including 2.4.11

Complex to apply

I expect Focus Appearance would be hard to apply, because the Success Criterion text has a lot of complexity. It is full of clauses and sub clauses. It often includes “and” (8 times), “or” (7 times) and “non”/“not” (4 times). There are two ways to meet it (you can choose one or both), and there are two exceptions and three notes. All in all, it's a lot to grasp.

The wording requires knowledge of a lot of specialised terminology, especially in the “area of the focus indicator” part. It may be that I am a non-native English speaker, but I had to look up what a “perimeter” is. The Oxford Dictionary of English states:

the continuous line forming the boundary of a closed geometrical figure

WCAG 2.2 makes this definition more specific to the web by defining “perimeter” as ”continuous line forming the boundary of a shape not including shared pixels, or the minimum bounding box, whichever is shortest”.

In this, “minimum bounding box” has its own definition:

the smallest enclosing rectangle aligned to the horizontal axis within which all the points of a shape lie

And because it is about web content, another clause is added:

For components which wrap onto multiple lines as part of a sentence or block of text (such as hypertext links), the bounding box is based on how the component would appear on a single line.

This is a lot to take in and it seems easy to misunderstand. There are so many sub definitions needed. One could easily misinterpret the concepts of a bounding box, the perimeter,“shared pixels”, “CSS pixels” (ok, that's already used in Reflow and Target Size) and apply the whole SC wrongly.

This makes 2.4.11 Focus Appearance very different from other criteria, like Non-Text Content or Keyboard. Accessibility specialists will know there are indeed lots of ways not to meet those requirements, but the general idea of how to comply is easier to grasp. Very few people will need to look up what a keyboard or text is.

Admittedly, there are easy ways to comply with the proposed Focus Appearance, too. One is to have a solid outline with a minimal offset of 1px that has sufficient contrast (3 : 1) with its background, as James Edwards explains in New Success Criteria in WCAG 2.2.

Complex to teach

As someone who sometimes teaches WCAG to teams, I also worry about the complexity of 2.4.11. I could teach the ‘easy way’ described above, that doesn't seem too complex to teach. But if I would try to teach the whole Success Criterion with all the requirements, exceptions and notes and also cover what the Understanding document explains, I fear I won't get it across.

“But teaching is your job, Hidde!”, you might say. Yes. And I could probably make it work, but it would take class time that I would like to spend on other barriers, and there is still the risk the information sticks with participants less because of the complexity. There will also be people trying to apply this Success Criterion on their own.

Leave it to browsers

We can't just leave all of our problems to browsers to fix. But if I had any say in it, browsers should fix any accessibility problems they are able to fix. That way, end users have to rely less on individual web developers to make good choices. I feel focus indication is a great example of that: the browser knows what has focus, users want to know it, web developers could fail to add a good indicator. So why rely on web developers?

In a discussion on relying on browsers for focus indication, the Working Group concluded that browsers don't do sufficient default focus indication today, so if we want accessible websites, we need to require it through WCAG. If browsers start to do it later, the requirement could be removed or moved to a different level then. A chicken and egg situation, basically, but with one of them more likely to materialise (I'm not super sure which, to be honest).

A second argument is that web designers are in a better position to design an appropriate indicator, one that fits well with the rest of the site's design. But it's unlikely those designers can take into account user needs as well as a browser could with settings. Some users may prefer an indicator they can see move from one element to another, some may want a very high contrast indicator, some may want it more subtle (see also Rain's comment mentioning high visible focus indicator from a COGA perspective). A browser could provide options. We wouldn't want individual websites to start offering focus indication choosers, right?

Forced focus indication already exists in various forms through OS settings, assistive technologies (like VoiceOver) and even some (buried away) browser settings (in Chrome). There is a bunch of browser plugins and bookmarklets that force focus indication, too. So we've got forced visibility. Forced “good appearance”, however, is not fully in browsers and harder to implement, of course. It would need to account for all the things 2.4.11 requires, like sufficient contrast with surroundings (the browser/add-on/plugin would need to make it work with any background) and sufficient contrast with non-focused state.

I get the idea of putting this on developers before full browser support exists, but it does feel a bit like solving all problems with one (conformance-shaped) hammer. It also doesn't apply when developers simply don't meet WCAG. Yes, there are human rights, ethics and laws, but we know they are violated a lot today. I fear this will only be more common when the requirements are too complex.

How to make it less complex

I know WCAG 2.2 is close to its last standardisation stages, so I'm sorry to bring this up now. I also don't want to just say ‘don't include 2.4.11’. Let me describe a possible way to make the situation less complex for developers, evaluators and teachers, by replacing Focus Appearance with multiple Success Criteria:

• Focus Distance to require a minimum offset between the focused element and its outline
• Focus Solid to require solid, unless a minimum thickness is used

These two on their own seem a lot less complex to apply, test and teach. As minimum contrast and visibility are already covered in other Success Criteria, these two criteria between them would make focus indication much better for low vision users, while not adding the complexity 2.4.11 adds.

Conclusion

The proposed Focus Appearance criterion does a great job at capturing which problems end users have around focus into requirements. But it lacks understandability for users of the standard: people who make websites, people who evaluate accessibility conformance, developers of testing tools, et cetera.

It may seem reasonable to say those understandability concerns are secondary to the ability of end users to use the web. Of course they are. But if there is too much complexity in WCAG wording and mathematics, I worry the web won't actually get better for end users. We'll lose the people who need follow the recommendations. This is already an issue with current requirements, as shown by the many “WCAG in plain words” derivatives and checklists that exist. The original source gets plenty of “appropriate requirements love”, it could use content design love.

I'm sorry, but I feel WCAG 2.2 is better off without 2.4.11. Even after some iterations, it (still) adds more complexity than we should want WCAG to have. It's difficult to apply and teach. It may end up like Terms and Conditions: factually correct, but commonly skipped over. That would be problematic in this case, and mean not considering important end user needs.

My ideal resolution would be (I know, easier said than done): sit down with browser makers and improve the focus indication game structurally together. Meanwhile, people who make websites can prioritise the 86 other WCAG Sucess Criteria (rather than implementing 2.4.11 until browsers are ready). Focus indicators are a core need web users have, it needs better appearance and likely choice in appearance, let's bring the research from AGWG into (browser) practice.

Originally posted as 2.4.11 Focus Appearance adds more complexity to WCAG than we should want on Hidde's blog.

Reply via email

OK, you've added an accessible name to your control. Maybe you've used aria-label, <label> or some other way to name a control. Now you wonder: what makes a name good, effective or useful?

I wrote about why accessible names matter and where to add them before. In this post, I will go into how to make the actual names more user friendly. These tips are all from an underappreciated piece of content that I love: the Composing Effective and User-Friendly Accessible Names section of the ARIA Authoring Practices Guide. All credits go to the authors, I'm just adding context and examples.

Function over form

An accessible name is used by assistive technologies to refer to things on a web page. For instance, if you use voice control, you could say the accessible name of a particular control to activate it. If you use a screenreader, it is the name that gets read out when you get to the control, or when you pull up a list of controls (eg a list of links on the page).

Because of how we use accessible names, we want to keep them functional and avoid naming controls after what they look like. Ideally, you do this in the imperative form, that makes it easiest to quickly grasp what a thing is going to do.

Examples:

• “Open navigation” works better than “Hamburger” and “More options” better than “Kebab”
• “Next slide” works better than “Arrow right” or “Right pointing triangle”
• “Save document” works better than “Floppy disk”

Most unique part first

In a series of names, like a set of buttons, links, etc, start with the most unique part of the name. This makes it easier to distinguish them.

Let's say you list a bunch of albums and want to include “album” in each name. Most unique first means you say “Midnight Marauders - Album”, “To Pimp A Butterfly - Album” etc, rather than “Album - Midnight Marauders”, “Album - To Pimp A Butterfly”.

Or you have actions for a link: “Edit link”, “Copy link” and “Share link” work better than “Link edit”, “Link copy” and “Link share”.

This even applies to the <title> of web pages: if you're repeating your company name in it, leave it for last and list what's unique about the page first. Technically not an accessible name, but the same naming advice happens to apply.

Be concise

Keep a name to the most important 1-3 words, prefer brevity.

No roles as part of the name

Things that have names in your page will (or should) have roles too. The browser will derive the role for you, whether you've set it explicitly (e.g. role="button") or it comes for free with the element (e.g. <button>). If you add the role, for instance the word ‘button’, to the name, that is redundant and this can be annoying for users.

Examples:

• use “Close” instead of “Close button”
• use “Main” instead of “Main nav”
• use “Save” instead of “Save button”

Keep names unique

Imagine you work in a school and all your students are named “Alice”. It would be hard to address them… this is the same for the names of controls and components in your page, especially for users who use mostly these names to browse the page.

Examples:

• instead of an overview page that shows news items with “read more” links, use the title of each news item as the link name
• instead of saying “click here”, use the name of the page you're linking too, for instance: “See also: [name of the page]”

Sentences aren't names

The last tip in the document is: start names with a capital letter, for better pronounciation in some screenreaders, and don't end with a period, because a name is not a sentence.

I'm not sure if this is the type that this tip is originally referring to, but one example of setences in accessible names is this: a card that has a title, a description and a picture, that is clickable as a whole, implemented by wrapping it all in one <a> element. I've seen this in the wild. It is often problematic, because it creates names that are way too long and confusing. My recommendation would be to do this instead: pick a string that is a more useful (and concise) name and make that the <a>. Then solve the clickability issue with CSS.

Wrapping up

Before I wrap up, I want to assure you that you don't need to use ARIA to provide names, even if this information is part of the ARIA Authoring Practices. Text content in the appropriate HTML elements (<label>, <legend>, <caption>, <button>, <a>) works perfectly fine too. An added benefit is that when you provide visible names with these HTML elements, they can be used by more users, including people who don't use assistive technologies and people collaborating with assistive technology users.

That's all. As mentioned above, these tips are from Composing Effective and User-Friendly Accessible Names in the W3C's ARIA Authoring Practices. That specific page has a lot more tips and also covers accessible descriptions, name and description calculation, per-role guidance on whether you need a name, lots of gotchas and various coding techniques for adding names. Happy naming!

Originally posted as Better accessible names on Hidde's blog.

Reply via email

The last dConstruct is a wrap! Jeremy did a great job curating a day that was (loosely) themed around “design transformation”. Here's my writeup of the day.

How does content survive 100 years?

When designing Flickr, George Oates tried to design a “context for interaction, not just an application”. It worked. Flickr allowed people to post content and connect it through tags, comments and more. Today, the site has 50 billion pictures posted by millions of people, making it, in Jason Scott's words, “a world heritage site”. Archivists may have kilometres of underground storage where they keep historical records, a site like Flickr is unique, as so many people contributed to it. For future generations, the sheer amount of visual data could give away a lot about life today. But Flickr isn't a given. Changing owners a few times, the site was almost killed and all content deleted. Now, at Flickr Foundation, George thinks about keeping this content for the future. And by future, she means the next 100 years. Long term preservation most likely needs selection, George clarified, maybe by letting users mark specific photos of theirs as keepworthy. Maybe it needs printing after all, as we are not sure if JPGs or PDFs are still readable in a 100 years. And how do we preserve a picture that is part of a network, if we can only preserve part of that network? How does this wealth of content survive economic forces and corporate whimsey?

George's team mapping out 100 years

These questions made me worry about the content I create online: blog posts, tweets, videos… it's on my personal website that I'm most sure there won't be corporate whimsey, but it's also unlikely to survive when I'm not around to pay the hosting bills. Should I update my testament?

The fun part of writing is the research

Lauren Beukes is a best-selling author. She travels a lot and said she actually enjoys the all this research more than the actual writing. On these trips, Lauren talks to a lot of people, from detectives in Detroit to teenage theatre geeks. She learns from their perspectives, takes in their sometimes horrifying stories and learns how they are treated by the system. Part of what a novelist does, she explained, is asking “what if?”.

Transformation through type

Type designer and calligrapher Seb Lester showed how a typeface he started designing on a train, came out 8 months later and started getting used. It was on washing powder, sky scrapers and olympic games branding. “When a typeface goes out in the world”, Seb explained, “a little bit of you goes out in the world”. The font was everywhere, but hardly anyone had heard of him (he said). Until he started publishing letter forms and calligraphy on social media. Seb's calligraphy videos and a cheeky comment in an interview in Salon got him jobs designing visuals for rocket scientists and Apple. His videos of lettering in progress are extremely soothing to watch, transforming from what seems like a few scribbles into beautiful works of art. Seb's stories were a reminder that success is very much a combination of two things: you want to “work hard”, “find your passion” and “believe in yourself” on the one hand, and be lucky and get noticed by the right people at the right time on the other. That last part is out of your hands, so you can only really try to do the first.

TFW NASA takes note

Design to make the world better

Daniel Burka has been a designer for a long time. He worked on the Firefox brand for Mozilla, which was interesting because of open source and their mission. He worked on Digg, which was interesting because of their scale. He worked on a game called Glitch, which was interesting because the creators of Flickr were involved, and Glitch became Slack). And then he worked at Google Ventures, where he met a number of companies working on life sciences related products. Then he came to realise that while designers in Silicon Valley are often in a very comfortable position, a lot of the world isn't well designed. This resonated with me: some of our largest's design budgets are used to solve trivial problems, like yet another food delivery service. Education, healthcare, financial services… they are long-term and hard problems. Highly regulated, too, and not very used to having designers on their teams. Daniel ended up working on Resolve to Save Lives, where he makes software that makes it easier to register data about high blood pressure patients. This sort of data saves lives by making it easier to get patients to return regularly. But clinicians want to spend time on patients, not data entry. The technological layer needs to be very light, to be effective.

Beware of tech utopians

In technology we trust. So much, that the Paris climate agreement—essential to humanity's survival on earth—is based on the assumption that technological inventions will be available. Techno-utopianism is not new, Sarah Angliss explained. She told us about Muriel Howorth, who was an amateur nuclear scientist who reckoned that if radiation could be used for atomic bombs, it could be used for atomic gardening. Howorth wanted to use “atom-blasted” seeds to grow a giant vegetable. Sarah also discussed an experiment in which fluoride, which is toxic in high quantities, was added to a city's water supply, with high expectations around improving the citizen's dental health, and “saxton spanglish”, a phonetic and somewhat controversial method of teaching children English. It reminded me of pinyin, that is sometimes used to teach non-native speakers Mandarin Chinese and also controversial for oversimplification and making proper learning harder. They are all attempts to transform through design, that are a little too utopian. Maybe another modern day equivalent, besides climate tech optimism, is that once so popular social network that frantically tries to make the ‘metaverse’ work, or even that we try and sprinkle machine learning on everything, even where it doesn't necessarily make sense (see AI for content creation). Yes, it could work, but it could not.

Computers need to get better at togetherness

Matt Webb talked about reinventing the workplace. One major reinvention was when the personal computer made its debut (see also: the setup). Here's some utopianism that did end up well. Screens, documents, text processing, the mouse: the mission to put a computer on every desk (and Douglas Engelbart's “mother of all demos”) completely reshaped what offices looked like. Speaking of design transformation! Matt noted how, fascinatingly, much of the history of computing is about furniture design. I didn't know Herman Miller worked with Doug Engelbart's team to invent furniture to go along with their machines. Is the office done? Not really, as in 2022 we increasingly find ourselves working together from different locations. The current state of “togetherness” is lacking, Matt explained. We can be in virtual rooms together, but it isn't as good as it could be. For instance, they don't have a window out—you can't see who's approaching the space. There is little of the serendipity you might find in a physical office. With Sparkle, Matt works on a Zoom replacement, a tool that aims to facilitate togetherness better. As a remote worker, and as someone who isn't sure Big Tech has the solution for us, I will be following this work.

Moonlander with applause-controlled lasers

Lasers: they are fascinating. Seb Lee-Delisle showed us how he took animations outside of the projected screen to kick off Smashing Conference in Oxford, displayed love for the NHS onto their Brighton building during the pandemic and displayed laser fireworks that people could interact with. It's impressive, really, how much even one laser can do, let alone the over 30 in different strengths that he currently owns. Seb had the arcade game Moonlander (I had to look it up) projected on the wall with lasers, so that we could all try and safely land a moon lander by affecting the vehicle's thrust with our applause.

Everyone perceives differently

Anil Seth concluded the day with a talk about perception. Questions about how we perceive the world outside and our own bodies have puzzled philosohopers for millennia. Today, neuroscientists try to confirm through experiments that we don't perceive the world directly, showing some of these philosophers were correct. Sensory input, Anil explained, is constantly processed by our brain—it fills in the gaps based on what it remembers of the past and predicts of the future. Seb's lasers had just demonstrated that: when he made his laser move in a circle, we perceived a static circle, not that movement. Just like a film is really 60 different images per second… our brain causes us to perceive it as a film. Anil drew an interesting parallel between perception (“controlled hallucination”) and halluccination (“uncontrolled perception”). This constant interpretation of input by individual brains implies what Anil calls “perceptual diversity”, everyone perceives differently. In an art installation called Dream Machine, participants' perception is triggered and then recorded in the form of drawings afterwards.

Wrapping up

There was a bit of design transformation in each of these talks. We were rightly warned about tech utopianism. Design and technology can't transform everything, yet some speakers shared their plans to transform. They (re)defined what it means to perceive ourselves, collaborate on screens or keep content available over a long stretch of time. Some speakers were right in the process of transforming. They talked about turning a series of penstrokes into art, lasers into fireworks, human experiences into novels and patient data collection into a minimal effort task.

A lot of our work in web design and technology has a power to transform and that is wonderful, especially when we manage to be intentional about the how and why. With that, I'll conclude this write up of the last dConstruct. If it piqued your curiosity, word goes that audio of the full event was recorded. It will be added to the dConstruct Archive in due time. For now, thanks Clearleft for another excellent event.

Originally posted as The last dConstruct on Hidde's blog.

Reply via email

WCAG 2.2 is the next version of the Web Content Accessibility Guidelines, published 5 October 2023. It includes all of WCAG 2.1, minus 4.1.1 Parsing, plus nine new criteria. Of those, six are in Level A + AA, the most commonly tested combination of levels.

Let's look at how you could meet the new Level A + AA criteria (note: this is just my summary and interpretation, for the official specification and wording, refer to WCAG 2.2):

1. Focus Not Obscured (Minimum) (2.4.11, AA): don't obscure the element that has focus (eg with sticky headers/footers or modals)
2. Dragging Movements (2.5.7, AA): when some action in your UI requires dragging, ensure the same action can also be performed without dragging (with a “single pointer”). Example: a map that can be dragged to move around, but also offers buttons to move up, down, left and right.
3. Target Size (Minimum) (2.5.8, AA): ensure that things you can click (or otherwise “point”, eg using pen, touch etc), are more than the specified minimum size, unless there's enough distance, it's inline or the small size is “essential”
4. Consistent Help (3.2.6, A): if your page/app contains help options, they are in the same order across pages (unless user zooms/turns device; these kinds of user-initiated changes are excepted)
5. Redundant Entry (3.3.7, A): avoid that users have to enter the same information twice, instead auto-populate or allow previous input to be selected. Some exceptions apply.
6. Accessible Authentication (Minimum) (3.3.8, AA): if your auth requires a “cognitive function test” (user has to remember, manipulate or transcribe), offer a way without such a test, or allow for assistance (eg support password managers, don't block copy/paste)

One SC was removed: Parsing (4.1.1). It existed because assistive technologies had to parse HTML, but they no longer do so directly.

Notably, the new SC Focus Appearance (2.4.13), that was initially put in Level AA, is going to be Level AAA. It has requirements for what focus styles look like, regarding contrast, size of the contrasting area and contrast of adjacent colors (this one may be the most tricky and “at risk”, but there's a lot of examples in Understanding Focus Appearance)

An overview of the new criteria, including examples of how they are useful to real people can be found on What's new in WCAG 2.2.

Originally posted as What's new in WCAG 2.2? on Hidde's blog.

Reply via email

Morten described a possible feature, maybe even reality, in which AI-generated content is rampant. But when we start to employ machine learning for content creation, we start to regard content as a means more than an end. In that process, won't we lose what's worth caring about?

In his post, Morten explains he sees three types of AI-generated content emerge. The first two, AI-curated content (it helps assemble content and provide you with what it thinks is the most relevant), and AI-assisted content creation (it contributes to content creation) are a thing now. The third, AI-synthesised content, will likely become a thing in the future. Morten's post gives a great overview of what to expect.

It reminded me of a project I did in university about automating the arts. My conclusion: we can write code to generate creative works, but code or models can't capture intentions, experiences or beliefs. This requires human input, therefore creating art (or content) requires human input, was my reasoning. There are nuanced differences between AI, machine learning, big data and bots, but in this post I won't go into them.

When I want to find a recipe for pizza dough on the web, I would consider myself lucky if I could get ahold of a blog post from someone who cares passionately about the right kind of dough, who maybe ran an artisan pizza kitchen in Naples for the past 30 years or has a background in baking. ‘Dream on’, you think. Well, these people exist on the web and the web is awesome for being an open platform that anyone with a passion can write on. I don't want to find text produced just because someone saw “pizza dough” is a common search phrase and a potential for top result ad money to be extracted. The passion that drives them isn't the pizza dough—that's fine, but it makes their content less relevant to me. Similarly, I also don't want to find text generated by a machine learning model. It can't possibly bring the knowledge and experience I'm hoping for.

When I write an email or reply, I try to put what I want to convey into words that I choose. I might choose to include an inside joke that me and the recipient share, fit in an appropriate cultural reference, be extremely polite, or terribly rude. I mean, my intentions and attitude are in that interaction. I don't want Google or LinkedIn or others to suggest what to reply, to reinforce reminiscences of the historical content they trained their machine learning models with. It dehumanises my conversation. Its suggestion may or may not align with my intentions.

When I listen to music, I can be touched by the experiences and world views that inspired the artist. Whether you're into the Eagles, Eels or Ella Fitzgerald, their songs capture things that machine learning systems can't because the artists have attitudes. Robots don't love and they don't have opinions. Maybe they can come up with interesting rhythms and melodies, or utter sentences like “I love you”, but the association of their work with intentions and memories needs humans.

When I read a newspaper, the order of pages, the focus a layout provides and the choice of photography… they are decided by human beings who have a lot of experience. People who work as a journalist after being a professional sports player for decades. People who followed politics for decades and therefore understand which scandal is worth extra attention. People who can make bold choices based on their world views. Bots don't have world views. Algorithmic prioritisation of content isn't as good as prioritisation by humans, even if it gets close. See also algorithmic timelines on social media versus human-curated lists and contextualisation.

When I have a consumer issue, I want to talk to a human representative of the company. Someone who has the authority to make decisions. Who can take us on the shortest path to a mutually satisfactory solution. Did you ever see a chat bot provide more than a repeat of the data it has been fed? Did you see a chat bot make enquiries with empathy? Lack of empathy isn't a bug in bots that we just haven't fixed yet, it arguably isn't empathy if it isn't human-to-human (ok maybe animals can be part of this equation).

All these examples lead me to think: the human side of data isn't measurable or computable. The human side of art, content or communication is not just a different side of the same coin, it's a bigger coin. There is more to reality than data can capture, like lived experiences from actual people and intentions and beliefs. Propositional attitudes that robots can only pretend to have.

Basically, I'm worried about overestimating how many human capacities machine learning can take over. At the same time, I don't think machine learning is useless. Quite the opposite, it is fantastic. I love it that computers are getting better at automated captions, translation or even generating images based on prompts. The latter may create a whole new level of art where artists use it as a material for their creations (see also AI is your new design material by Josh Clarke). Medical applications where machine learning notices abnormalities that a human might miss. Audio recognition engines that will tell you what song is playing. Email spam filters that save us all a lot of time. It's all super valuable and genuinely impressive. And a lot of these use cases don't need lived experiences, intentions or beliefs to be incredibly useful.

Originally posted as Re: AI for content creation on Hidde's blog.

Reply via email