본문으로 건너뛰기

© 2026 Molayo

Smashing헤드라인2026. 05. 20. 01:26

Figma Variables를 활용한 접근성(Accessibility) 목적의 폰트 스케일링 테스트

요약

디지털 접근성을 단순한 추가 기능이 아닌 비즈니스 부가가치이자 법적 의무로 인식하고, 이를 팀의 일상적인 루틴에 통합하는 'AccessibilityOps'의 중요성을 강조합니다. 특히 Figma Variables를 활용하여 폰트 스케일링과 같은 접근성 요소를 디자인 프로세스 내에서 효율적으로 테스트하고 구현하는 방법을 제안합니다.

핵심 포인트

  • 접근성은 선택 사항이 아닌 비즈니스 가치이자 법적 의무임
  • AccessibilityOps를 통해 접근성 작업을 팀의 일상적인 워크플로우에 통합해야 함
  • 디자인 시 색상 대비뿐만 아니라 폰트 크기, 상호작용 크기 등 다각적인 관점이 필요함
  • 사용자의 보조 기술(스크린 리더, 폰트 확대 등)을 고려한 유연한 디자인 설계가 중요함

기업 내에 진정한 디지털 접근성 (Digital Accessibility) 문화를 구축하는 것은 회복 탄력성과 인내심이 필요한 미션입니다. 접근성에 관한 담론이 흔한 상투적인 문구로 빠지는 것은 어렵지 않은 일입니다. "접근성은 사람들에게 매우 중요합니다. 디지털 제품과 서비스의 접근성은 포용성을 증진합니다. 혹은 팀의 모든 전문가가 접근성 작업에 참여해야 합니다." 물론입니다. 제정신인 사람이라면 이 중 어떤 문장도 부정하지 않을 것입니다 (그러길 바랍니다).

하지만 아주 적은 수의 기업만이 도달하는 대화의 두 번째 부분은 바로 "어떻게?(how?)"입니다. 우리 모두가 알다시피, 매우 제한된 인원으로 까다로운 스크립트(scripts)에 몰두하고 있는 디지털 전환 (Digital Transformation) 팀의 일상적인 업무 속에서 어떻게 이를 실현할 수 있을까요? 대부분의 경우, 선택은 결국 "이것을 할 것인가"와 "저것을 할 것인가" 사이에서 끝나게 됩니다. 그리고 이는 결코 그래서는 안 됩니다. 왜냐하면 이런 경우, 저는 이 방정식에서 접근성이 승리하는 것을 본 적이 없기 때문입니다.

상황이 이래서는 안 됩니다. 여러분도 이럴 필요가 없습니다. 우선, 접근성과 다른 무엇인가 사이에서 선택하는 것은 올바른 선택이 아니기 때문입니다. 접근성은 더 이상 다른 기능들에 추가되는 또 하나의 기능이 아닙니다. 그것은 비즈니스를 위한 부가가치이며, 현재로서는 기업에 심각한 결과를 초래할 수 있는 법적 의무입니다. 반면에, 팀의 자연스러운 역동성에 접근성 원칙을 통합할 수 있는 지능적이고 최적화되었으며 영향력 있는 방법들이 존재합니다. 팀의 운영을 뒤엎지 않고도 접근성 작업을 수행하는 것이 가능합니다. 본질적으로, 그것이 바로 AccessibilityOps가 하는 일입니다. 사람들에게 권한을 부여하고 (Empowering people), 팀에게 단순한 프로세스를 제공하여 (providing teams with simple processes), 그들이 과도한 노력 없이도 접근성 작업을 일상적인 루틴에 통합할 수 있도록 (integrate accessibility work into their daily routines) 하는 것입니다.

접근성 (Accessibility) 및 디자인 (Design)

디자인에서 디지털 접근성 (Digital Accessibility)을 작업하는 데에는 여러 가지 활동이 포함될 수 있습니다. 색상과 그 색상이 의미를 전달하기 위해 어떻게 사용되는지에 대해 특별한 주의를 기울여야 한다는 점은 명확합니다. 물론, 요소들의 상호작용 크기 (Interaction sizes) 또한 편안해야 합니다. 하지만 가장 중요한 것은, 우리가 다각적인 관점에서 디자인을 생각해야 한다는 점입니다. 인터페이스는 포스터가 아닙니다. 우리는 디자인의 많은 측면을 제어할 수 있지만, 사용자가 인터페이스와 상호작용하는 방식은 무수히 많은 변수에 달려 있습니다. 기기의 종류, 맥락 (Context), 목적, 네트워크 품질 등이 그 예입니다. 이 모든 것들은 각 개인의 경험과 상호작용에 큰 영향을 미칩니다. 이와 더불어, 디자인 프로세스에 디지털 접근성 관련 고려 사항이 도입되면 변수는 더욱 늘어납니다.

사람들은 흔히 **보조 기술 및 전략 (Assistive technologies and strategies)**이라고 불리는 것들을 사용합니다. 기본적으로 이것들은 사람들이 더 편안한 사용 모델을 찾기 위해 의존하는 기술적 도구이거나, 최소한 일종의 "요령"이라고 할 수 있습니다. 예를 들어, 흔히 시각 장애인의 사용과 연관되지만 그들에게만 유용한 것은 아닌 유명한 스크린 리더 (Screen readers)가 보조 기술의 한 예입니다. 서로 다른 요소 간의 색상이나 색상 대비 (Color contrasts)를 변경하는 것 또한 보조 기술입니다. 폰트 크기를 키우는 것(이 글에서 논의한 내용)도 또 다른 예입니다. 이처럼 셀 수 없이 많은 보조 기술과 전략이 존재하며, 이는 거의 각 개인의 다양한 사용 맥락만큼이나 다양합니다.

우리가 모든 것을 제어할 수는 없습니다

다시 말해 (그리고 이것은 디자이너인 우리에게는 "나쁜 소식"입니다), 사용자의 관점에서 "우리의 디자인"은 우리가 제어할 수 없는 변형의 대상이 됩니다. 사용자는 애플리케이션과 그 기능이 제공하는 모든 것을 가능한 가장 편안한 방식으로 상호작용할 수 있도록 디자인을 "변형"할 것입니다. 그리고 그것은 좋은 일입니다. 만약 이런 일이 일어나고 모든 것이 원활하게 진행된다면, 우리는 접근성 (Accessibility) 작업을 매우 잘 수행한 것이며, 우리 모두는 축하받을 자격이 있습니다. 만약 사용자가 이러한 지원 기술 (Support technologies)이나 전략 중 하나를 적용했음에도 여전히 디지털 애플리케이션을 사용할 수 없다면, 이는 무언가가 의도대로 작동하지 않고 있다는 신호입니다.

아, 그리고 말이 나온 김에 말하자면, 이러한 기술이나 지원 전략의 사용을 차단할 생각은 꿈에도 하지 마세요. 그것들이 당신의 아름다운 디자인을 "망치고" 있을지는 몰라도, 점점 더 많은 사람들이 실제로 앱을 사용할 수 있게 해주고 있습니다. 결국, 그것이 바로 우리가 하고 싶다고 약속했던 일이 아니었나요? 예외 없이, (모든) 사람을 위한 디자인 말입니다.

글꼴 크기 키우기 (Increase Font Size)

친구, 가족, 혹은 동료로부터 이 글자나 저 글자가 너무 작다고 불평하는 소리를 얼마나 많이 들어보았나요? 텍스트는 디지털 경험에서 매우 중요한 역할을 합니다. 사용법 안내, 버튼 캡션(Button captions), 또는 상호작용 요소(Interactive elements)와 같이 많은 정보가 텍스트를 통해 전달됩니다. 이 모든 것들은 텍스트를 소통 도구로 사용합니다. 만약 이 모든 요소를 읽는 것이 어렵다면, 당연히 경험은 심각하게 저해될 것입니다.

기능에 관계없이 편안한 텍스트 읽기는 타협할 수 없는 원칙입니다. 이러한 읽기 경험은 디자인에서 편안한 크기를 사용함으로써 촉진될 수 있습니다. 하지만 폰트 크기를 키우는 기능과 같은 보조 기술 및 전략 또한 가독성(Readability)을 개선하는 데 도움을 줄 수 있습니다. APPT 데이터에 따르면, **Android 및 iOS 모바일 기기 사용자의 26%**가 기본 폰트 크기를 키웁니다 (2026년 2월 데이터). 사용자 4명 중 1명은 스마트폰에서 폰트 크기를 키우고 있습니다. 이는 매우 상당한 표본이며, 디자인 프로세스에서 이 기능이 필수적임을 의미합니다.

가이드라인 준수 (Compliance With Guidelines)

인터페이스에서 폰트 크기를 키우는 것은 디자인 측면에서 매우 큰 도전 과제가 될 수 있습니다. 사용자의 행동으로 인해 일부 텍스트 요소가 초기 크기에서 갑자기 두 배로 커질 수 있다는 점을 이해하는 것이 중요합니다.

“캡션(Captions)과 텍스트 이미지(Text images)를 제외하고, 텍스트는 보조 기술(Assistive technology) 없이도 콘텐츠나 기능의 손실 없이 최대 200%까지 크기를 조정할 수 있어야 한다.”

— 웹 콘텐츠 접근성 가이드라인 (WCAG) 버전 2.2, 성공 기준 1.4.4, “텍스트 크기 조정 (Resizing Text)”

이 성공 기준은 AA 준수 수준에 해당하며, 이는 어떤 법적 프레임워크에 따르더라도 반드시 갖춰야 하는 필수 기능임을 의미합니다.

이 성공 기준의 200%는 이해하기 쉽습니다. 만약 우리가 인터페이스를 100% 스케일(즉, 요소의 크기가 초기 크기임)로 디자인한다고 가정하면, 텍스트를 최대 200%까지 키우는 것은 초기 크기의 두 배가 되는 것에 해당합니다. 120%, 140% 등 다른 확대 스케일도 사용할 수 있습니다. 다시 말해, 우리는 사용자가 보조 기술이나 전략을 통해 텍스트를 초기 크기의 두 배까지 키울 수 있도록 보장해야 합니다 (그리고 이것은 사소한 디테일이 아닙니다).

이 표준을 준수하기 위해, 인터페이스 내에 별도의 텍스트 크기 확대 도구를 제공할 필요는 없습니다. 실제로 이러한 기능은 중복에 불과합니다. 기기들은 이미 이러한 작업을 표준화된 방식으로 수행할 수 있도록 지원하고 있습니다. 이 설정이 정말로 필요한 사용자들은 이를 이미 알고 있습니다 (왜냐하면, 이 기능이 없다면 그들의 삶은 훨씬 더 어려워질 것이기 때문입니다). 즉, 그들은 이미 기기 전체에 이 설정을 적용해 둔 상태입니다. 따라서 우리는 이러한 추가적인 인터페이스 요소를 제거하여 경험을 단순화할 수 있습니다.

표준화된 접근 (Standardized Access)

보조 기술 (Assistive technologies), 특히 이번 사례와 같이 폰트 크기를 키우는 것과 관련하여 기억해야 할 중요한 개념은 대부분의 기기에 이미 이러한 도구들이 기본적으로 설치되어 있다는 점입니다. 다시 말해, 많은 경우 사용자가 이 기능을 사용하기 위해 별도의 소프트웨어를 구매하거나 특정 유형의 기기를 살 필요가 없습니다.

모바일 기기든 웹 브라우저든, 대다수의 경우 인터페이스 전반에 사용 중인 기본 폰트 크기를 키울 수 있도록 설치된 기능을 쉽게 찾을 수 있습니다. 이러한 폰트 크기 확대 원칙은 앱과 같은 디지털 제품이나, 오늘날 사용되는 표준 웹 브라우저에서 실행되는 모든 유형의 웹사이트에도 적용될 수 있습니다.

iPhones

iPhone 기기에서는 폰트 크기 확대 기능이 기본적으로 통합되어 있습니다. 이 기능을 사용하려면 단순히 "설정 (Settings)" 패널에 접속하여 "손쉬운 사용 (Accessibility)"을 선택한 다음, "시각 지원 (Vision)" 옵션 그룹 내에서 "텍스트 크기 및 디스플레이 (Text Size and Display)" 기능에 접속하여 해당 화면에서 원하는 폰트 크기 확대를 구성하면 됩니다.

Google Chrome

웹 브라우저 또한 기본적으로 폰트 크기를 키우는 기능을 제공합니다. 예를 들어, Google Chrome의 경우 이 기능은 “설정 (Options)” 패널, 구체적으로는 “모양 (Appearance)” 영역에서 사용할 수 있습니다. 이 그룹에 나타나는 옵션 목록에서 단순히 “글꼴 크기 (Font size)” 옵션을 선택하면 됩니다. 보통은 “중간 — 권장 (Medium — Recommended)” 옵션이 선택되어 있습니다. 이 설정을 사용 가능한 다른 어떤 폰트 크기로도 변경할 수 있습니다. 예를 들어, “매우 크게 (Very large)” 옵션을 시도해 보세요.

Figma에서 테스트하기

디지털 접근성 (Digital Accessibility) 작업이 팀의 일상생활에서 효과를 발휘하기 위해서는 **단순한 작업 프로세스 (Simple work processes)**를 찾는 것이 필수적입니다. 팀의 루틴에 통합될 수 있고, 접근성을 통합적인 방식으로 다루며, 현재의 현실을 급격하게 변화시킬 필요가 없는 행동이나 이니셔티브가 필요합니다. 만약 급격한 변화가 필요하다면, 그는 대부분의 경우 그런 일은 일어나지 않을 것이라고 믿습니다. 따라서 단순한 작업 프로세스를 설계하는 것은, 이 사례의 경우 디자인 팀 내에서도 접근성이 진정으로 실현되게 만드는 데 있어 절반의 승리를 거두는 것과 같습니다.

디자인에서 폰트 크기 확대를 테스트하는 것과 관련하여, 우리는 오늘날 사용할 수 있는 놀라운 도구들을 가지고 있습니다. Adobe Photoshop에서 복잡한 인터페이스를 디자인하던 시절을 기억하는 사람이라면 오늘날 우리가 가진 도구의 차이를 알아차릴 것입니다 (그리고 다행히도 그렇습니다). 이제 Figma와 같은 도구를 통해 디자인에 역동성을 부여할 수 있으며, 이를 통해 접근성을 위한 폰트 크기 확대 테스트가 팀에게 거의 피할 수 없는 과정이 되도록 만들 수 있습니다.

참고: 이 테스트를 수행하려면 Figma의 텍스트 스타일 (Text styles), 오토 레이아웃 (Auto layouts), 그리고 변수 (Variables)에 대한 강력한 이해가 필요합니다. 이 세 가지는 큰 추가 노력 없이도 성공을 이끌어낼 수 있는 핵심적인 도구입니다. 만약 아직 이 기능들을 마스터하지 못했다면, 거기서부터 시작할 것을 강력히 권장합니다. 단계를 건너뛰지 마세요. 학습은 구조화된 단계에 따라 점진적으로 따라야 하는 과정입니다.

우리는 어디로 가고자 하는가?

우리가 수행하고자 하는 Figma에서의 폰트 크기 증가 테스트는 간단합니다. 인터페이스에서 사용하는 모든 텍스트 스타일(Text Styles)에 대해 사용할 수 있는 변수(Variables) 세트를 마련하여, 인터페이스를 100%, 120%, 140%, 160%, 180%, 또는 200%의 스케일로 볼 것인지 선택할 수 있도록 하는 것입니다. 이 변수 세트를 적용하면 (라이트 모드와 다크 모드를 위한 변수를 적용하는 것과 매우 유사하게), 인터페이스 내 텍스트의 변화를 관찰하고, 서로 다른 타이포그래피 스케일(Typographic Scales)을 가진 각 인터페이스 버전에서 어느 정도의 적응(Adaptations)이 필요한지 이해할 수 있습니다.

어떻게 이를 실현할 것인가?

이 테스트가 원활하게 진행되려면 기초 작업을 수행해야 합니다. 디자인 시스템(Design Systems)은 이러한 초기 작업의 상당 부분을 최적화하는 데 큰 도움이 될 수 있습니다. 하지만 솔직히 말씀드리자면, 테스트가 제대로 작동하려면 디자인이 매우 높은 수준의 조직화와 체계화(Systematization)를 갖추고 있어야 합니다.

이것은 엄밀히 말해 가이드라인은 아닙니다. 각 팀마다 고유한 작업 모델이 있을 것이고, 이러한 권장 사항들은 다양한 방식으로 적용될 수 있기 때문입니다 (그것은 괜찮습니다). 하지만 이 테스트가 작동하려면 디자인에서 특정 가정들을 확실히 해두는 것이 중요합니다. 이 테스트 모델의 구현 단계를 나누는 데 도움을 드리기 위해, 따라야 할 몇 가지 단계가 있습니다. 파일을 정리하고 가장 단순하며 실용적인 방식으로 이 테스트를 완전히 실행할 수 있도록 안내하는 단계별 지침입니다.

1. 인터페이스 디자인하기

모든 것은 디자인에서 시작됩니다. 어떤 테스트를 수행하기 전에는, 당연히 나중에 테스트할 각 인터페이스의 디자인에 집중해야 합니다. 이 단계에서는 나중에 수행할 폰트 크기 증가 테스트에 대한 구체적인 고려 사항은 아직 없습니다. 당연하게도, 모든 인터페이스 디자인은 시작부터 디자인에 적용되는 가장 기본적인 접근성(Accessibility) 권장 사항을 따라야 합니다.

2. 모든 요소에 오토 레이아웃(Auto Layouts) 적용하기

여러분이 만드는 모든 화면 디자인에서 오토 레이아웃 (Auto Layouts)을 완벽하게 적용했는지 반드시 확인해야 합니다. 이는 매우 중요한 단계입니다. 전체 구조와 디자인 요소에 오토 레이아웃을 일관되게 적용하는 작업이야말로, 나중에 폰트 크기 증가를 테스트하기 시작할 때 인터페이스의 확장성 (Scalability)을 보장해 주는 핵심 요소가 됩니다. 이 단계의 중요성을 결코 과소평가해서는 안 됩니다. 만약 이 단계에 마땅한 주의를 기울이지 않는다면, 인터페이스에서 타이포그래피 스케일링 (Typographic Scaling)을 테스트할 때 모든 것이 마치 '도자기 가게 안의 코끼리(elephant in a china shop, 매우 서툴고 파괴적인 모습)'처럼 망가지는 것을 보게 될 것입니다.

3. 텍스트 스타일 (Text Styles) 구조화 및 적용하기

AI 자동 생성 콘텐츠

본 콘텐츠는 Smashing Magazine의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0