An inclusive app puts people first by prioritizing respectful communication and presenting content and functionality in ways that everyone can access and understand.
포용적인 앱은 존중하는 의사소통을 우선시하며 모든 사람이 이해하고 접근할 수 있는 방식으로 콘텐츠 및 기능을 제공함으로써 사람을 최우선으로 생각합니다.
→ 포용적인 앱은 모든 사람을 고려함
역자 첨언
To help you design an inclusive app, consider the following goals as you review the words and images you use and the experiences you offer.
포용적인 앱을 디자인하는 데 도움이 되도록, 사용하는 단어와 이미지, 그리고 제공하는 경험 등을 검토할 때 다음 목표를 고려하십시오.
→ 하단의 내용을 활용하여 포용적인 앱을 디자인하는 것을 권장
As with all design, designing an inclusive app is an iterative process that takes time to get right. Throughout the process, be prepared to examine your assumptions about how other people think and feel and be open to evolving knowledge and understanding.
모든 디자인과 마찬가지로, 포용적인 앱을 디자인하는 것은 시간이 걸리는 반복적인 과정입니다. 이 과정에서 다른 사람들이 어떻게 생각하고 느끼는지에 대한 가정을 검토하고, 지식과 이해가 계속해서 발전될 수 있도록 열려 있어야 합니다.
→ 포용적인 앱을 디자인하기 위해 많은 시간을 투자해 다양한 사람을 이해하려하고 앱의 기능을 검토
Simple, intuitive experiences are at the core of well-designed apps. To design an intuitive experience, you start by investigating people’s goals and perspectives so you can present content that resonates with them.
간결하고 직관적인 경험은 잘 디자인된 앱의 핵심입니다. 직관적인 경험을 디자인하려면, 사람들의 목표와 시각을 조사하여 그들이 공감할 수 있는 콘텐츠를 제공해야 합니다.
→ 사람들을 분석하여 공감할 수 있는 콘텐츠를 직관적으로 제공하기
Empathy is an important tool in this investigation because it helps you understand how people with different perspectives might respond to the content and experiences you create. For example, you might discover that from some perspectives a word or image in your app is incomprehensible or has a meaning you don’t intend.
이러한 조사에서 공감은 중요한 도구입니다. 다양한 시각을 가진 사람들이 어떻게 콘텐츠나 경험에 반응할 수 있는지 이해하는 데 도움이 됩니다. 예를 들어, 앱의 어떤 단어나 이미지가 어떤 시각에서는 이해할 수 없거나 의도와 다른 의미를 가지고 있다는 것을 발견할 수 있습니다.
→ 사용자가 이미지나 컨텐츠를 이해할 수 있는 문화나 지적 수준을 가졌는지 파악하기
역자 첨언
Although each person’s perspective comprises a unique intersection of human qualities that’s both distinct and dynamic, all perspectives arise from human characteristics and experiences that everyone shares, including:
각 개인의 관점은 독특하면서도 구별되며 동적인 인간적인 특성들의 고유한 교차점으로 이루어져 있지만, 모든 관점은 인간들이 공유하는 인간적인 특성과 경험에서 비롯됩니다. 이러한 특성과 경험에는 다음과 같은 것들이 포함됩니다:
→ 사용자를 분석할 때 고려해야 할 것은 아래와 같다
역자 첨언
• Age
• Gender and gender identity
• Race and ethnicity
• Sexuality
• Physical attributes
• Cognitive attributes
• Permanent, temporary, and situational disabilities
• Language and culture
• Religion
• Education
• Social and economic context
•
나이
•
성별 및 성 정체성
•
인종과 민족성
•
성
•
신체적 특성
•
인지적 특성
•
영구적, 일시적, 상황적 장애
•
언어와 문화
•
종교
•
교육 수준
•
정치적 또는 철학적 견해
•
사회적 및 경제적 배경
As you examine your app through different perspectives, avoid framing the work as merely a search for content that might give offense. Although no app should contain offensive material or experiences, an inoffensive app isn’t necessarily an inclusive app. Focusing on inclusion can help you avoid potentially offensive content while also helping you create a welcoming experience that everyone can enjoy.
다양한 시각에서 앱을 검토할 때, 일부 사용자를 불쾌하게 할 수 있는 콘텐츠를 찾는 것으로만 초점을 맞추면 안됩니다. 모든 앱은 불쾌한 콘텐츠나 경험을 포함해서는 안 되지만, 불쾌하지 않은 앱이 포괄적인 것은 아닙니다. 포괄성에 초점을 맞추면 잠재적으로 불쾌한 콘텐츠를 피할 뿐만 아니라 모든 사용자가 즐길 수 있는 환영받는 경험을 만들 수 있습니다.
→ 포괄성을 갖추기 위해, 모든 사용자가 즐길 수 있고 불쾌한 콘텐츠를 피할 수 있게 하기
역자 첨언
Using plain, inclusive language welcomes everyone and helps them understand your app. Carefully review the writing in your app to make sure that your tone and words don’t exclude people. Here are a few tips for writing text — also known as copy — that’s direct, easy to understand, and inclusive.
평이하고 포괄적인 언어를 사용하면 모든 사람을 환영하고 그들이 앱을 이해하는 데 도움이 됩니다. 앱 내의 글쓰기를 신중하게 검토하여 톤과 단어가 사람들을 배제하지 않는지 확인하십시오. 여기 몇 가지 직접적이고 이해하기 쉽고 포괄적인 텍스트 쓰기 팁이 있습니다.
→ 하단의 팁들을 활용하여 포괄적인 언어 톤과 단어를 사용하면 사용자가 앱을 이해하는 것이 수월해짐
Consider the tone of your copy from different perspectives. The style of your writing communicates almost as much as the words you use. Although different apps use different communication styles, make sure the tone you use doesn’t send messages you don’t intend. For example, an academic tone can make an app seem like it welcomes only high levels of education. As you seek the style that’s right for your app, focus on being clear, direct, and respectful.
다양한 시각에서 어조 또는 톤을 고려하세요. 당신의 글의 스타일은 당신이 사용하는 단어들과 거의 비슷하게 의사소통합니다. 서로 다른 앱이 다른 의사 소통 스타일을 사용하지만, 사용하는 톤이 의도하지 않은 메시지를 전달하지 않도록 하십시오. 예를 들어 학술적인 톤은 높은 교육 수준을 가진 사람들만 환영한다는 느낌을 줄 수 있습니다. 앱에 적합한 스타일을 찾으며 명확하고 직접적이며 상호 존중하는 것에 집중하십시오.
→ 자신의 말투를 그대로 앱에 활용하지 말고, 다양한 시각으로 유저가 환영 받을 수 있게 어조나 톤을 고려하기
역자 첨언
Pay attention to how you refer to people. It typically works well to use you and your to address people directly. Referring to people indirectly as users or the user can make your app feel distant and unwelcoming. Also, consider reserving words like we and our to represent your app or company; otherwise, these terms can suggest a personal relationship with people that might be interpreted as insulting or condescending.
사람들을 언급할 때 주의하세요. 일반적으로 직접적으로 사람들을 대상으로하는 you 와 your를 사용하는 것이 잘 작동합니다. 간접적으로 사용자 또는 사용자들 과 같은 용어를 사용하면 앱과 거리감이 느껴지고 환영받지 않게 느껴질 수 있습니다. 또한 we와 our 같은 용어는 앱이나 회사를 대표하는 데 사용하는 것이 좋습니다. 그렇지 않으면 이 용어들은 사람들과 개인적인 관계를 가진 것처럼 인식될 수 있으며 모욕적이거나 경멸적으로 해석될 수 있습니다.
→ 사용자를 지칭할 때는 you or your, 앱이나 회사를 지칭할 때는 we or our, 이외에는 사용을 자제하기
Avoid using specialized or technical terms without defining them. Using specialized or technical terms can make your writing more succinct, but doing so excludes people who don’t know what the terms mean. If you must use such terms, be sure to define them first and make the definitions easy for people to look up. Even when people know the definition of a specialized or technical term in a sentence, the sentence is easier to read — and translate — when it uses plain language instead.
전문 용어나 전문 용어를 정의하지 않고 사용하지 마세요. 전문 용어를 사용하면 글이 간결해지지만, 용어를 모르는 사람들은 배제될 수 있습니다. 반드시 그러한 용어를 사용해야 하는 경우, 먼저 정의하고 이를 쉽게 찾을 수 있도록 해야 합니다. 전문 용어의 정의를 이미 알고 있더라도, 문장은 평문을 사용할 때 더 쉽게 읽히며 번역하기도 쉬워집니다.
→ 전문용어를 사용을 최대한 피하고, 꼭 필요하다면 정의를 제공하고 찾기 쉽게 해야 함
Replace colloquial expressions with plain language. Colloquial expressions are often culture-specific and can be difficult to translate. Worse, some colloquial phrases have exclusionary meanings you might not know. For example, the phrases peanut gallery and grandfathered in both arose from oppressive contexts and continue to exclude people. Even when a colloquial phrase doesn’t have an exclusionary meaning, it can still exclude everyone who doesn’t understand it.
colloquial expressions을 평문으로 바꾸세요. colloquial expressions은 종종 문화적으로 특정되며 번역하기 어렵습니다. 더 나쁜 것은 일부 colloquial expressions이 배제적인 의미를 지니고 있을 수 있다는 점입니다. 예를 들어, "peanut gallery"와 "grandfathered in"이라는 구문은 억압적인 맥락에서 비롯되었으며, 지금도 사람들을 배제합니다. colloquial expressions이 배제적인 의미가 없더라도, 이를 이해하지 못하는 모든 사람을 배제할 수 있습니다.
→ colloquial expressions을 사용하지 않기
역자 첨언
Consider carefully before including humor. Humor is highly subjective and — similar to colloquial expressions — difficult to translate from one culture to another. Including humor in your app risks confusing people who donʼt understand it, irritating people who tire of repeatedly encountering it, and insulting people who interpret it differently. For additional writing guidance, see Writing inclusively.
유머를 포함하기 전에 신중히 고려하세요. 유머는 매우 주관적이며, colloquial expressions과 마찬가지로 한 문화에서 다른 문화로 번역하기 어렵습니다. 앱에 유머를 포함하는 것은 이를 이해하지 못하는 사람들을 혼란스럽게 만들고, 반복적으로 마주치기 지겨운 사람들을 짜증나게 만들며, 이를 다르게 해석하는 사람들을 모욕하는 위험이 있습니다. 추가적인 작성 지침은 Writing inclusively 를 참조하세요.
→ 유머는 사람마다 문화마다 해석이 다를 수 있으니 신중히 사용
An approachable app doesn’t require people to have particular skills or knowledge before they can use it, and it gives people a clear path toward deepening their understanding over time.
접근 가능한 앱은 사용자들이 특정 기술이나 지식이 없어도 사용할 수 있으며, 이해를 깊이 있는 수준으로 확장할 수 있는 명확한 경로를 제공합니다.
Whether your app enables a range of powerful functions or performs one simple task, here are two ways to make it approachable.
앱이 강력한 기능 범위를 지원하거나 하나의 간단한 작업을 수행하는 경우 모두, 접근 가능하게 만드는 두 가지 방법이 있습니다.
→ 어떤 앱을 개발하던, 하단의 두 방법을 활용하여 앱의 접근성을 높이기
• Present a clear, straightforward interface. To help you design a simple interface that fits in with other apps on each platform, see Designing for visionOS, Designing for iOS, Designing for iPadOS, Designing for macOS, Designing for watchOS, and Designing for tvOS.
명확하고 직관적인 인터페이스를 제공하세요. 각 플랫폼의 다른 앱들과 맞춰진 간단한 인터페이스를 디자인하기 위해 visionOS, iOS, iPadOS, macOS, watchOS, 그리고 tvOS에 대한 디자인 가이드를 확인하세요.
→ 명확하고 직관적인 인터페이스를 제공하세요. 그리고 디자인 가이드를 활용하여 개발
• Build in ways to learn how to use your app. Consider designing a first-launch experience that helps new users take a step-by-step approach while letting experienced users skip straight to the content they want. For guidance, see Onboarding.
사용자가 앱을 사용하는 방법을 배울 수 있는 방법을 제공하세요. 새로운 사용자들이 단계별로 접근할 수 있는 첫 실행 경험을 디자인하고, 경험이 있는 사용자들은 바로 원하는 콘텐츠로 건너뛸 수 있도록 고려하세요. 지침은 Onboarding을 참조하세요.
→ 새로운 사용자를 위해 Onboarding을 활용하세요. Onboarding skip 기능은 필수
Throughout history, cultures around the world have recognized a spectrum of self-identity and expression that expands beyond the binary variants of woman and man.
역사를 거치면서, 전 세계의 문화에서는 여성과 남성의 두가지 형태를 넘는 개인의 정체성과 표현의 스펙트럼을 인정해왔습니다.
You can help everyone feel welcome in your app by avoiding unnecessary references to specific genders. For example, a recipe-sharing app that uses copy like “You can let a subscriber post his or her recipes to your shared folder” could avoid unnecessary gender references by using an alternative like “Subscribers can post recipes to your shared folder.” In addition to using the gender-neutral noun “subscribers,” the revised copy avoids the unnecessary singular pronouns “his” and “her,” helping the sentence remain inclusive when it’s localized for languages that use gendered pronouns.
여러분의 앱에서 특정 성별에 대한 불필요한 언급을 피하면 모든 사람이 환영받는 느낌을 받을 수 있습니다. 예를 들어, “구독자가 그녀의 레시피를 공유 폴더에 게시할 수 있습니다”와 같이 “그녀”와 “그”와 같은 성별 지칭어를 사용하지 않고 대안으로 “구독자들이 공유 폴더에 레시피를 게시할 수 있습니다”와 같이 성별 중립적인 명사를 사용하는 것이 불필요한 성별 지칭어를 피하는 방법입니다. 또한, 단수 대명사 “his”와 “her”를 사용하지 않고 성별 대명사를 사용하는 언어에 적합하게 수정함으로써 문장이 지역화되어도 포함적인 문장으로 유지되도록 합니다.
→ 성별 지칭어를 사용하지 않고 성별 중립적인 명사를 사용
Another example of an unnecessary reference to a specific gender is in an avatar, emoji, or glyph. To welcome everyone, give people the tools they need to create avatars and emoji that represent them accurately. When it’s necessary to depict a generic person or people, use a nongendered human image to reinforce the message that generic person means human, not man or woman. SF Symbols provides many nongendered glyphs you can use, such as the figure and person symbols shown here:
특정 성별을 가리키는 불필요한 표현의 또 다른 예시는 아바타, 이모지 또는 글리프(glyph)에서 찾을 수 있습니다. 모든 사람을 환영하기 위해서는 사람들이 자신을 정확하게 대표할 수 있는 아바타와 이모지를 만들 수 있는 도구를 제공해야 합니다. 일반적인 사람 또는 사람들을 묘사할 필요가 있을 때는 일반적인 사람이란 인간을 의미하는 것이라는 메시지를 강조하기 위해 성별이 없는 인간 이미지를 사용해야 합니다. SF Symbols에는 여러 성별이 없는 글리프(glyph)가 제공되며, 여기에 나와 있는 사람과 인간 심볼 등이 포함됩니다.
→ 성별을 꼭 특정해야 할 필요가 없다면, 중성적인 이미지, 아바타, 이모지, 글리프등을 사용
person.crop.circle
person.3.fill
figure.wave
Most apps don’t need to know a person’s gender, but if your app requires this information — such as for health or legal reasons — consider providing inclusive options, such as nonbinary, self-identify, and decline to state. In this situation, you could also let people specify the pronouns they use so you can address them properly when necessary.
대부분의 앱은 사람들의 성별을 알 필요가 없지만, 건강 또는 법적인 이유로 이 정보가 필요한 경우, 남성 여성으로 나눈 것이 아닌, 자가 식별 및 선택하지 않음과 같은 포용적인 옵션을 제공하는 것이 좋습니다. 이 상황에서, 사용자들이 사용하는 대명사를 지정할 수 있도록 하여 필요할 때 적절하게 대응할 수 있도록 할 수도 있습니다.
→ 성별을 꼭 사용해야 한다면, 다양한 선택지를 제공하고, 사용자가 지정한 대명사를 활용하는 방법을 고려하기
역자 첨언
Portraying human diversity is one of the most noticeable ways your app can welcome everyone. When people recognize others like themselves within an app and its related materials, they’re less likely to feel excluded and can be more likely to think they’ll benefit from the app.
인간 다양성을 표현하는 것은 당신의 앱이 모두를 환영하는 데 가장 눈에 띄는 방법 중 하나입니다. 사람들은 앱과 관련 자료에서 자신과 비슷한 다른 사람들을 인식할 때, 제외되지 않았다고 생각하고 앱을 사용할 가능성이 높아집니다.
→ 앱에서 인간의 다양성을 표현하여, 많은 사용자가 앱을 사용하게 해야 함
As you create copy and images that represent people, portray a range of human characteristics and activities. For example, a fitness app could feature exercise moves demonstrated by people with different racial backgrounds, body types, ages, and physical capabilities. If you need to depict common occupations, avoid stereotypical representations, such as showing only male doctors or female nurses.
사람을 나타내는 복사본과 이미지를 만들 때 다양한 인간적 특성과 활동을 나타내도록 노력하세요. 예를 들어, 피트니스 앱은 다른 인종 배경, 체형, 연령 및 신체 능력을 가진 사람들이 수행하는 운동 동작을 보여줄 수 있습니다. 일반적인 직업을 묘사해야 하는 경우, 남성 의사나 여성 간호사만을 보여주는 것과 같은 편견적인 묘사는 피해야 합니다.
→ 사람을 나타내는 상징을 만들 때, 특정한 인간의 특성을 살려 편견적인 묘사를 하지 말아야 함
Also review the settings and objects you show. For example, showing high levels of affluence might make sense in some scenarios, but in other cases it can be unwelcoming and make an app seem out of touch. When it makes sense in your app, prefer showing places, homes, activities, and items that are familiar and relatable to most people.
또한 당신이 보여주는 설정과 object들도 검토하세요. 예를 들어, 일부 상황에서 고수준의 부유함을 보여주는 것이 타당할 수 있지만, 다른 경우에는 반갑지 않을 수 있으며 앱에 접근하기 어려워 보일 수 있습니다. 당신의 앱에서 설정과 object들이 의미가 있게 하려면, 대부분의 사람들이 친숙하게 느끼고 공감할 수 있는 장소, 집, 활동 및 항목을 선호해야 합니다.
→ 앱 사용자가 친숙하고 공감할 수 있는 설정과 objects를 사용
역자 첨언
Everyone holds biases and stereotypes — often unconsciously — and it can be challenging to discover how they affect your thoughts. A goal of inclusive design is to become aware of your biases and generalizations so you can recognize where they might influence your design decisions.
우리는 모두 편견과 고정 관념을 가지고 있습니다 - 종종 무의식적으로 - 그리고 그것들이 여러분의 생각에 어떻게 영향을 미치는지 발견하는 것은 어려울 수 있습니다. inclusive design의 목표는 당신의 편견과 일반화를 인식하여 당신이 설계 결정에서 영향을 미칠 수 있는 부분을 인식할 수 있게 하는 것입니다.
→ inclusive design의 목적은, 설계자의 일반화된 편견이 설계 결정에 영향을 미칠 수 있는 곳을 인식시키는 것
For example, consider an app that helps people manage account access for various family members. If this app uses a stereotypical definition of family — such as a woman, a man, and their biological children — it’s likely to communicate this perspective in its copy and images. Because the app assumes that people’s families fit this narrow definition, it excludes everyone whose family is different.
예를 들어, 가족 구성원의 계정 접근을 관리하는 앱을 생각해보겠습니다. 만약 이 앱이 가족을 여성, 남성, 그리고 그들의 생물학적 자녀로 고정관념의 정의를 사용한다면, 이러한 시각을 문구와 이미지에 전달할 가능성이 높습니다. 앱이 사람들의 가족이 이 한정된 정의에 맞는다고 가정하면, 가족이 다른 형태인 모든 사람을 제외 시키게 됩니다.
→ 예시: 부모 그리고 자식의 형태만 가족 구성원이라고 가정하는 것
Although the assumption made in the account-access app might seem like an obvious mistake, it’s important to realize that not all assumptions are so easy to spot. For example, consider an app that requires people to choose security questions they can answer for future identity confirmation, such as:
계정 액세스 앱에서 assumption이 명백한 실수처럼 보일 수 있지만, 모든 assumption의 오류가 쉽게 발견되는 것은 아니라는 것을 깨닫는 것이 중요합니다. 예를 들어, 사람들이 다음과 같은 신원 확인을 위해 대답할 수 있는 보안 질문을 선택하도록 요구하는 앱을 생각해 보십시오:
→ 계정 접근 앱에서 포용성에 관한 실수
•
What was your favorite subject in college?
•
당신이 대학에서 가장 좋아했던 과목은 무엇인가요?
•
What was the make of your first car?
•
당신이 처음으로 산 자동차의 제조사는 무엇인가요?
•
How did you feel when you first saw a rainbow?
•
당신이 무지개를 처음 본 순간의 기분은 어떤가요?
From some perspectives these questions refer to commonplace events, but all are based on experiences that not everyone has. Using a context-specific experience to communicate something is useless for everyone who doesn’t share that context and effectively excludes them. To create alternatives to the culture- and capability-specific questions above, you might reference more universal human experiences like:
이러한 질문들은 어떤 관점에서는 일상적인 경험을 가리키지만, 그들 모두가 경험하지 않은 상황에서는 쓸모가 없습니다. 특정 문화나 능력에 특화된 경험을 사용하여 메시지를 전달하면, 해당 문화나 능력을 공유하지 않는 모든 사람을 배제하게 됩니다. 이러한 문제를 해결하기 위해, 대신 더 보편적인 인간 경험을 참조하여 문항을 만드는 것이 좋습니다. 예를 들면 다음과 같습니다:
→ 계정 접근 앱의 포용성을 더 높이기 위해, 신원 확인 시 인간의 더욱 보편적인 경험을 질문에 사용하도록 하기
•
What’s your favorite hobby?
•
당신이 가장 좋아하는 취미는 무엇인가요?
•
What was the name of your first friend?
•
당신의 첫 번째 친구의 이름은 무엇인가요?
•
What quality describes you best?
•
당신을 가장 잘 표현하는 특징은 무엇인가요?
Basing design decisions on stereotypes or assumptions inevitably leads to exclusion because generalizations can’t reflect the diversity of human perspectives. Avoiding assumptions and instead focusing on inclusion can help you craft experiences that benefit everyone.
다양한 인간 관점을 반영할 수 없기 때문에, 일반화와 편견에 기반한 디자인 결정은 반드시 배제로 이어집니다. 가정을 하지 않고 포용에 집중하는 것은 모두에게 이로운 경험을 제공하는 디자인을 만드는 데 도움이 될 수 있습니다.
→ 가정, 고정관념 등을 사용하지 않고 앱의 포용성에 집중하기
An inclusive app is accessible to everyone. People rely on Apple’s accessibility features — such as VoiceOver, Display Accommodations, closed captioning, Switch Control, and Speak Screen — to customize their devices for their individual needs, so it’s essential to support these features in your app.
포괄적인 앱은 모든 사람들이 접근할 수 있도록 설계되어야 합니다. 사람들은 VoiceOver, Display Accommodations, closed captioning, Switch Control, Speak Screen과 같은 애플의 접근성 기능에 의존하여 기기를 자신의 개별적인 필요에 맞게 사용합니다. 따라서 앱에서 이러한 기능을 지원하는 것이 중요합니다.
→ 애플의 접근성 기능을 앱에 구현하기
역자 첨언
It’s also essential to avoid assuming that any disability might prevent someone from wanting to use your app. Making an assumption like this can result in designs that limit an app’s potential audience. In contrast, when you focus on making each app experience accessible, you give everyone the opportunity to benefit from your app in ways that work for them.
또한, 장애로 인해 다른 사람이 앱을 사용하지 못할 수 있다는 가정을 피하는 것도 중요합니다. 이러한 가정은 앱의 잠재적인 대상자를 제한하는 디자인 결과를 초래할 수 있습니다. 반면, 모든 앱 경험을 접근 가능하게 만드는 것은 모든 사람이 자신에게 맞는 방식으로 앱을 활용할 수 있는 기회를 제공합니다.
To help you design an app that everyone can enjoy, remember that:
모든 사람이 즐길 수 있는 앱을 디자인하기 위해, 다음을 기억해주세요:
→ 하단을 참조하여, 모든 사람이 자신에게 맞는 방식으로 앱을 활용할 수 있게 디자인 하기
•
Each disability is a spectrum. For example, visual disabilities range from low vision to complete blindness, and include things like color blindness, blurry vision, light sensitivity, and peripheral vision loss.
•
각 장애는 스펙트럼입니다. 예를 들어, 시각적 장애는 낮은 시력에서 완전한 보이지 않음까지 이어지며, 색맹, 시야 흐림, 빛에 대한 민감도, 주변 시야 손실 등이 포함됩니다.
•
Everyone can experience disabilities. In addition to disabilities that most people experience as they age, there are temporary disabilities — like short-term hearing loss due to an infection — and situational disabilities — like being unable to hear while on a noisy train — that can affect everyone at various times.
•
모든 사람이 장애를 경험할 수 있습니다. 나이가 들면서 대다수의 사람들이 경험하는 장애 외에도, 감기로 인한 단기간 청각 장애와 같은 일시적 장애 및 시끄러운 기차에서는 들을 수 없는 상황적 장애 같은 것들이 모든 사람에게 영향을 줄 수 있습니다.
→ 모든 사람이 장애를 경험할 수 있음
As you design content that welcomes people of all abilities, consider the following tips.
모든 능력의 사람들을 환영하는 콘텐츠를 디자인하면서, 다음 팁들을 고려해보세요.
Avoid images and language that exclude people with disabilities. For example, include people with disabilities when you represent a variety of people, and avoid language that uses a disability to express a negative quality.
장애를 가진 사람들을 배제하는 이미지와 언어를 피하세요. 예를 들어, 다양한 사람들을 나타낼 때 장애인도 포함시키고, 장애를 부정적인 특성으로 표현하는 언어는 피하세요.
→ 장애를 가진 사람을 특정 부류로 나누거나 부정적으로 표현하지 않기
Take a people-first approach when writing about people with disabilities. For example, you could describe an individual’s accomplishments and goals before mentioning a disability they may have. If you’re writing about a specific person or community, find out how they self-identify; for more guidance, see Writing about disability.
장애인에 대해 글을 쓸 때는 인간 중심적인 방식을 취하세요. 예를 들어, 개인이 가지고 있는 장애를 언급하기 전에 그들의 업적과 목표를 먼저 언급할 수 있습니다. 만약 특정 인물이나 커뮤니티에 대해 글을 쓴다면, 그들이 자신을 어떻게 생각하는지를 파악하세요. 더 자세한 안내는 장애에 대한 글쓰기를 참조하세요.
→ 개인에 대해서 글을 쓸 때, 업적과 목표를 먼저 언급하고 그들이 자신을 어떻게 생각하는지 파악하고 용어를 선택하는 등의 인간 중심적인 방식으로
역자 첨언
Prioritize simplicity and perceivability. Prefer familiar, consistent interactions that make tasks simple to perform, and ensure that everyone can perceive your content, whether they use sight, hearing, or touch.
단순성과 인식 가능성에 우선순위를 두세요. 사용자가 수행하기 쉬운 익숙하고 일관된 상호작용을 선호하며, 시력, 청력 또는 촉각을 사용하는 사람 모두가 콘텐츠를 인식할 수 있도록 보장하세요.
→ 일관적인 상호작용 형태로 시력, 청력, 촉각을 사용하는 모든 사용자가 앱을 사용할 수 있게 하기
People expect to customize their device by choosing a language for text and a region for formatting values like date, time, and money. To welcome a global audience, first prepare your app to handle languages and regions other than your own — a process called internationalization — and provide translated text and resources for specific locales. For an overview of internationalization, see Expanding your app to new markets; for developer guidance on localization, see Localization.
사람들은 텍스트 언어와 날짜, 시간, 돈과 같은 값의 형식을 선택하여 디바이스를 맞춤 설정할 수 있습니다. 전 세계의 대중을 환영하기 위해, 먼저 당신의 앱이 당신의 언어 및 지역 이외의 언어 및 지역을 처리할 수 있도록 준비하고 – internationalization 과정 – 특정 로케일에 대한 번역된 텍스트 및 리소스를 제공하세요. internationalization에 대한 개요는 Expanding your app to new markets을 참조하세요. localization에 대한 개발자 가이드는 Localizaton을 참조하세요.
→ 사용자의 범위를 전세계로 잡을 때, 세계화와 현지화의 과정을 거치기
역자 첨언
Creating an inclusive experience can also help you prepare for localization. For example, using plain language, avoiding unnecessary gender references, representing a variety of people, and avoiding stereotypes and culture-specific content, can put you in a good position to create versions of your app localized into more languages. Using SF Symbols for the glyphs in your app can also help streamline localization. In addition to providing many language-specific glyphs, SF Symbols includes glyphs you can use in both left-to-right and right-to-left contexts; for guidance, see Right to left.
inclusive한 경험을 만든다면 localization을 준비하는데 도움을 받을 수 있습니다. 예를 들어, 간단한 언어를 사용하고, 불필요한 성 차별을 피하고, 다양한 사람들을 대표하며, 고정 관념과 문화 특정 콘텐츠를 피하는 것은 귀하의 앱의 더 많은 언어로 로컬화된 버전을 만드는 좋은 위치에 있게합니다. 귀하의 앱에서 glyphs 위해 SF Symbols를 사용하면 로컬라이제이션을 간소화하는 데 도움이 됩니다. 많은 언어별 그리프뿐만 아니라, SF Symbols는 왼쪽에서 오른쪽 및 오른쪽에서 왼쪽 문맥에서 모두 사용할 수 있는 그리프를 포함하고 있습니다. 지침은 Right to left을 참조하세요.
→ inclusion에 초점을 맞춰 앱을 개발했다면, App의 현지화 시 쉽게 개발 가능함. + SF Symbols
역자 첨언
As you localize your app and related content, also be aware of the ways you use color. Colors often have strong culture-specific meanings, so it’s essential to discover how people respond to specific colors in each locale you support. In some places, for example, white is associated with death or grief, whereas in other places, it’s associated with purity or peace. If you use color as a way to communicate, make sure your color choices communicate the same thing in each version of your app.
당신이 앱과 관련된 콘텐츠를 지역화할 때, 색상을 사용하는 방법에도 주의해야 합니다. 색상은 종종 문화에 따라 강한 의미를 지니기 때문에, 지원하는 각 지역에서 사람들이 특정 색상에 어떻게 반응하는지 알아내는 것이 중요합니다. 예를 들어 어떤 곳에서는 흰색이 죽음이나 애도와 연관되지만, 다른 곳에서는 순수함이나 평화와 연관될 수 있습니다. 만약 색상을 의사소통 수단으로 사용한다면, 각 버전의 앱에서 동일한 의미를 전달할 수 있도록 색상 선택을 조심해야 합니다.
→ 지역, 문화마다 색깔에 대한 인식이 다름. App을 다른 지역의 사용자에게 배포 하려고 할 때 주의
Localization — Xcode
Change Log
작성 날짜 | 작성자 | 수정사항 |
2023/5/16 | 고석준 | 초기 번역 |
2023/12/22 | 고석준 | 배포 |