웹 접근성으로의 여행

Quotes, Web Accessibility, Web Standards 댓글 달기

내용 요약

“꼬리표(tag) 생성” 에서부터 “WYSIWOYS 생성”까지. Roberto Scano씨의 글에는 웹 세대 간 웹 접근성에 관한 문제들과 현재의 위치, 그리고 앞으로 우리가 기대할 수 있는 것들에 관해서 요약해 놓았다. 웹 접근성에 대해서 이해하고 고민하는 데 도움이 되는 글로 이곳에도 옮겨 놓는다.

저자: Roberto Scano

내용

맨 처음…

타임머신을 타고 바로 세기 전, 더 정확히 말하면, 20세기 후반 이제 막 웹이 태동하여 잠재력을 늘려가기 시작했을 때로 돌아가 보자.

웹의 첫 혁신은 1997년 1월 14일에 일어났다: HTML 3.2는 그 당시 웹 개발자들에게는 잘 알려지지 않았던 W3C라 불리는 협회에 의해 제안되었다. 문서의 소개 문장에서도 쓰여 있듯이, HTML 3.2는 HTML을 위한 W3C의 명세서로, 1996년 초에 개발되었으며, IBM, Microsoft, Netscape Communications Corporation, Novell, SoftQuad, Spyglass, 그리고 Sun Microsystems의 사업자들이 같이 참여했었다. HTML 3.2에는 당시 많이 적용되었던 테이블들, applets 그리고 그림 주위에 흐르는 글자와 같은 기능들을 추가했으며, 동시에 이미 존재했던 HTML 2.0 표준과도 완전한 호환을 제공하였다. 10 년 후, 지금은 역사 속의 얘기지만, 그 당시 초창기 첫 웹 개발자들과 학생들(특히 일반 사람들에게는 공개되기 전, 웹이 다루어질 수 있었던 대학 내의 사람들)은 그들의 첫 웹 페이지를 웹 브라우저에 내장되어 있던 편집기를 사용해서 개발하기 시작했었다. 나는 그 당시 유명했던 첫 버전의 웹 브라우저들을 기억하는데: NCSA Mosaic, Netscape, 또 Internet Explorer가 있었고, 또한 Winsock을 설정하는 것이 얼마나 어려웠었는지도 기억한다.

또한, CSS 1.0도 1997년에 등장했었지만, 그 당시에는 겉모양 치장은 HTML markup 요소들과 속성들을 적용해서 이루어졌었다. 예전의 브라우저들은 요새의 것들과는 달라서 거의 융통성이 없었다. 그래서 Mosaic 브라우저는 첫 HTML 오류 발견 시에는 그냥 문서 해독을 중지해버렸다. HTML 3.2가 처음 소개될 당시, 나중에 IWA로 합병된 HTML Writers Guild(HTML Writers Guild라는 단체는 1994 년에 설립되었다)에게는 HTML 개발을 위한 문서 생성과 편집 도구로는 오직 그들의 첫 쉐어웨어 / 무료 애플리케이션으로 간단한 글자 편집기들만이 존재했었다. 예를 들어, 내가 기억하기에는 1995년부터 사용되었던 첫 WYSIWYG 편집기 중에 AOLPress 2.0이라는 도구가 있었는데, 이것은 용법이 틀린 HTML 생성을 허용하지 않아서, HTML 3.2 혹은 W3C의 HTML 3.2 권장사항과 아주 약간의 차이를 가지고 있던 옛 Netscape의 HTML 버전의 용법에 적합하지 않게 쓰인 것들은 자동으로 이 도구에 의해 삭제되거나 고쳐졌었다. 이것들이 태그들(tags)과 속성들(attributes)을 인식하는 첫 HTML 편집기 세대였으며, 이들은 또한 그들이 생성하는 문서들은 시각적으로 편하고, 용법에도 맞으며, (그 당시 별로 사정이 좋지 못했던 인터넷 접속 상황으로 인해서) 코드가 너무 무겁지도 말아야 한다는 것을 이해하고 있었다. 그 시절에는 웹 접근성이라는 용어는 존재하지도, 또 필요하지도 않았었다.

[본문 내용으로]

첫 진화: 접근성과 HTML

몇 달 후, 1997 년 12 월 18 일, W3C는 첫 HTML 4.0 버전을 내놓고, 1998 년 4 월 24 일에 다시 개정판을 발표하게 된다. HTML 3.2와 다른 주요 차이점은? 다음과 같은 요소들이 추가되었다: ABBR, ACRONYM, BDO, BUTTON, COL, COLGROUP, DEL, FIELDSET, FRAME, FRAMESET, IFRAME, INS, LABEL, LEGEND, NOFRAMES, NOSCRIPT, OBJECT, OPTGROUP, PARAM, S (사용 안됨), SPAN, TBODY, TFOOT, THEAD, 그리고 Q. HTML 3.2의 요소들 중에서 더 이상 지원이 안되는 것들은: APPLET, BASEFONT, CENTER, DIR, FONT, ISINDEX, MENU, STRIKE, 그리고 U.

HTML 4.0은 처음으로 접근성에 관한 언급이 있었던 HTML 버전이다:

웹 기반 공동체의 덩치가 커지고 그 속의 구성원들도 가진 재능과 기술이 다변화되면서, 떠받치고 있는 기술도 그들의 입맛에 맞는 요구에 부응해야 하는 시점에 도달하게 되었다. 그래서 HTML은 신체적으로 장애를 갖고 있는 사람들에게도 웹 페이지들로의 접근이 더 손쉬워지도록 설계되었다. HTML 4.0의 개발은 다음과 같은 접근성을 염두에 두고 진행되었다:

  • 문서의 구조와 전달 방법 간의 더 명확한 구별, 따라서 HTML의 겉모양 표현을 위한 요소들과 속성들 대신에 스타일 쉬트(Style sheets)의 사용을 권장함.
  • 좀 더 다듬은 폼(forms), 접근 키의 추가를 포함한, 폼의 컨트롤들을 의미론적으로 한 데 묶을 수 있는 기능, SELECT 선택 사항들을 의미론적으로 같은 집단으로 묶을 수 있는 기능, 그리고 여기에 활용 가능한 꼬리표들(labels).
  • 추가한 객체(Objects)를 글자로 설명하는 코드(OBJECT 요소)를 사용해서 표시할 수 있게 하는 기능.
  • 클라이언트(client) 쪽의 새로운 그림 지도 구조( MAP 요소)로 웹 문서 편집자들에게 그림과 글자 링크들을 함께 섞어서 표시해 줄 수 있게 한다.
  • IMG 요소와 AREA 요소의 그림 지도 속 그림들과 함께 위치하면서 차선적으로 표시될 수 있는 설명의 글(alternate text)을 필수 요구사항으로 함.
  • 모든 요소들에 title과 lang 속성들을 지원.
  • ABBR과 ACRONYM 속성들을 지원.
  • 스타일 쉬트와 함께 사용될 수 있는 더 넓어진 범위의 대상 미디어(TTY, Braille, 등).
  • 제목, 열(column)의 묶음, 그리고 시각적으로 표시되지 못하는 표현을 수월하게 하기 위한 구조 등의 향상된 테이블(tables).
  • 테이블, 그림, 프레임(frames) 등의 긴 설명문.

이 시기는 그야말로 WYSIWYG 편집기들의 사용이 널리 유행하게 된 시점이라, table 요소와 같은 요소들이 겉치장만을 위한 목적으로 잘 못 사용되는 관습이 만연하게 된 결과를 가져오게 되었다. 초창기 문제가 되었던 테이블 표현 방법을 잘 이해하기 위해서는, HTML 4.0의 첫 버전에 명시된 글을 읽어보기를 권한다. 이 당시에는 또 웹사이트들에 사용될 템플레이트들(templates)의 생성을 위해 프레임들(frames)을 사용하려는 (별로 권장될 수만은 없는) 멋진 아이디어도 생겨났다. 이쯤에 와서, 나는 여러분에게 Transitional DTD의 머리말 첫 부분에 언급된 것들을 주지시키고 싶다:

이것은 HTML 4.0 과도기적(Transitional) DTD로, 겉모양의 표현을 목적으로 하는 속성들과 요소들을 포함하고 있지만, 이것들은 W3C에서는 스타일 쉬트가 어느 정도 성숙하여서 자리를 잡게 되면 사라질 것으로 기대하고 있다. 웹 문서 제작자들은 가능하면 Strict DTD를 사용할 것을 권하며, 겉모양 치중의 속성들과 요소들을 지원하는 것이 꼭 필요할 때에만 Transitional DTD를 사용할 것을 권한다.

새내기 웹 개발자들이 HTML DTD들의 지식 없이 WYSIWYG 편집기들을 사용하기 시작했을 때, 과도기적(Transitional) DTD가 널리 사용되었다. 왜 히필 과도기적 DTD이였냐고? 이러한 현상은 대부분 과도기적(Transitional) DTD가 “태그(tag)들의 잡탕”을 허용하는 데에서 찾아볼 수 있다. HTML 4.0에서부터는, 생성된 코드에 관한 규제가 불가능해져서, 새내기 웹 개발자들이 문서를 제작하는 과정에서 다음과 같은 몇 가지 큰 실수들을 저지르게 되었다:

  • 문서 배치를 위한 테이블들 – WYSIWYG 편집기들은 일반적으로 문서 배치를 위해 테이블들을 사용할 때 고정된 폭과 너비를 사용하고, 겉모양 표현을 위해 사용되면 안 되는 속성들을 추가하는 경향이 있었다.
  • 설명의 글 – WYSIWYG 편집기들은 그림들에 붙을 설명의 글을 자동으로 요구하지도 않았으며, 혹은 기껏해야 설명의 글로 파일 이름을 대신 사용했다. 프레임세트들(framesets)의 경우에도 마찬가지: 자주 보게되는 your browser doesn’t support frames라는 글도 frameset을 대시하는 설명의 글로 쓰이며, 오늘날에도 이 문제는 여전하다.
  • 머리말(Headings) – 머리말의 경우도, CSS를 사용하는 대신에, 겉모양의 효과만을 위해서 잘못 사용됐다.
  • 인용(Quotations) – <blockquote>와 같은 요소도, 요소의 원래 사용 목적에 맞게 사용되는 대신에, 시각적인 효과만을 위해 부적절하게 사용되었다.
  • 글꼴 – font 요소는, 해당 속성들과 함께, 문서 전체의 여기저기에 과도하게 쓰이고, 가끔은 규정도 따르지 않고 불규칙하게 포개어서 사용하는 때도 있었다.

어느 시점에 도달해서, 개발자들은 그들의 전문성과 웹 개발 지식에 있어서 다양한 수준의 능력과 지식을 갖게 되었다. 어떤 이는 HTML 요구사항들에 관한 지식을 얻게 되었고, 또 어떤 이는 (매우 드믈지만) 접근성에 관심을 갖게 되었지만, 대부분의 개발자들은 맹목적으로 WYSIWYG 편집기들을 그냥 MS Word처럼 사용하게 되었다. 그 당시에 사용 가능했던 WYSIWYG 편집기들은 적합한 HTML 코드를 생성하지 못 했었고, 또 몇몇 형편없는 것들은 그냥 Word 문서에서 베껴두기 & 붙이기가 가능해서, 전체 문서의 코드를 HTML 문서에다 복사해 놓는 경우도 있었다.

또한, 1998년에 W3C는 두 번째 버전의 CSS를 개발하였는데, 그 당시의 브라우저들은 최신 CSS를 제대로 지원하지 않거나 혹은 다르게 적용하는 경향이 있었다: 이것은 1998년의 상황이 과연 어떠했는지를 이해하는 데 도움이 될 만하다.

[본문 내용으로]

첫 진보: WYSIWYG vs. WCAG, ATAG, XHTML 그리고 CSS 2.0

1999년은 웹 꾸림정보의 접근성 지침(Web Content Accessibility Guidelines -WCAG)이 발표된 시기이다. 1999년 5월 5일, WCAG 1.0은 W3C 권고 사항이 되었다. 이것은 W3C Web Accessibility Initiative(WAI)에 의해 개발된 첫 국제적 지침으로 웹 개발자들에게 접근이 쉬운 웹 정보를 개발하는데 도움이 될 만한 정보를 제공하는데 그 목적이 있었다. 이를 계기로 해서, W3C는 개발자들에게 몇 가지의 지침서들을 제고하게 되었지만, 대다수의 웹 개발자들은 그 당시 WYSIWYG 편집 도구들을 사용하고 있었기 때문에 WCAG에 관심을 기울이지 못하는 커다란 문제를 안고 있었다.

미래의 편집 도구들이 생성할 정보의 내용과 편집 도구의 인터페이스들 모두에서 접근성을 확보해 두기 위해서 , W3C는 편집 도구들의 접근성 지침 (ATAG) 1.0, 그리고 HTML 4.01이 발표되었다.

같은 시기에, HTML 역사에 있어서 또 하나의 커다란 진전이 있었다: 2000년 1월 26일, W3C는 XHTML 1.0을 발표하게 되는데, 이것은 HTML 4를 개량한 XML 1.0 애플리케이션으로서, 세 가지의 DTD들은 각각 HTML 4에 정의되어 있는 것들과 비슷하였다. 여러 요소들과 각각의 속성들의 의미 체계는 HTML 4를 위한 W3C의 권고에 정의되어 있다. 이러한 의미 체계는 차후 XHTML의 확장성을 위한 기반을 제공하게 된다. 또한, 현존했던 HTML 유저 에이전트들(user agents)에 대한 호환은 Appendix C – HTML 호환 지침에 나와 있는 지침들을 따르면 가능하였다.

1999-2000년 사이 웹을 처음 접해본 사람들에게, 이와 같은 시나리오는 커다란 진전으로 비칠 수도 있다. 하지만, 편집 도구 개발자들에게는, 이것이 진보와는 전혀 다른 얘기였으며, 차후 다가올 몇 년 동안 DTD에 선언되었던 것들의 순응을 꿈꿔온 유토피아적 세상과는 거리가 점점 더 멀게 된다. 이러한 현상은 간단한 SGML 분석기를 사용하는 HTML Tidy와 같은 도구로 DTD에 선언된 것들을 제대로 따르는지 쉽게 확인할 수 있었다는 점을 고려해보면 매우 의외다. 이 시기는 MS Frontpage와 Dreamweaver의 시대였고, 이러한 도구들은 아직 접근성을 보장해 줄 준비가 되어 있지 않았었다. 그래서 외부 플러근인들(plugins)의 사용과 약간의 수정으로, 초기 개척자들은 접근하기 쉽고 표준을 따르는 웹 페이지의 생성을 지원하기 시작하였다.

웹 진보의 시점에서 웹 개발자들이 직면하고 있었던 가장 큰 문제점들은 무엇이었는가?

  • 쇠퇴한 WYSIWYG 편집기들. 시장에 나와 있던 주요 편집기들은 XHTML 1.0 DTD를 사용한 표준을 따르는 코드를 생성하지 못했다. 이러한 도구들이 가지고 있었던 가장 큰 문제는 새로운 웹 페이지들을 만들기 위한 원본들(templates)이 어떠한 표준 규칙들도 따르지 않았었고 또한 접근성 지침을 따르지도 않았었다.
  • W3C 권고 사항들에 대한 무지. 웹 개발자들은 웹 접근성을 위한 W3C의 권고 지침에 대한 이해가 모자랐었거나, 혹은 완전하게 모르고 있었다. 대신에, 이러한 지침들은 단지 “장애를 가진 사람들만을 위한 것”으로 이해하고 있었다. 결국, W3C 권고 사항들의 부족한 이해와 더불어, “첫 진보”에서 경험했던 같은 실수들이 계속 반복되었다.
  • 알 수 없는 문서의 구조. 편집기들이 가지고 있었던 가장 큰 단점은 사용자들에게 어떻게 하면 가장 적절한 구조의 문서를 구성할 수 있는지에 관한 지원이 없었다. 이것의 의미는, 예를 들어, WYSIWYG 편집기들을 사용할 때 머리말(heading) 구조를 조절할 수 없었다. 결과적으로, 개발자들은 blockquote, unordered lists, data tables, list 등과 같은 요소들을 부적절하게 사용하는 오류를 범하게 되었다.

[본문 내용으로]

CMS 세대: 눈에 보이는 것은 그야말로 단지 눈에 보이는 것들뿐?

이제 우리는 새로운 웹 기술들의 세대에 진입했다; XHTML 1.0 두 번째 판, XHTML 1.1, 그리고 늘어가는 다른 markup 언어들과 지원 기술들의 집합.

웹은 진보하였고, 그와 함께 더 복잡한 편집 도구들의 필요성도 증가하였다. 웹 브라우저 안에서 작동하는, 웹 애플리케이션이라고 불리는 애플리케이션들의 필요성도 생겨나서, 웹의 꾸림정보를 자동 생성해주는 것이 가능하게 되었다. 문서의 편집, 그림들과 문서 등의 전달, 이것이 바로 Content Management System(CMS)이다.

이 세대를 우리는 “눈에 보이는 것은 그야말로 단지 눈에 보이는 것들뿐(WYSIWOYS)”의 세대라고 부른다. 이 시점에 와서, 우리는 다름과 같은 또 다른 문제들에 부딪힌다.

  • 웹 애플리케이션들의 접근 불가성. 이것은 해결하기도 어렵거니와, “닫혀 있는” 웹 애플리케이션이든 오픈 소스 어플리케이션이든 모두에게 해당하며, 더 문제가 되는 것은 바로 두 번째 집단이다. 오픈 소스 프로젝트들은 접근성을 염두에 둘 수 있는 계기가 작을 수밖에 없고, 이것이 문제가 되는 것은 가령 CMS의 경우, 죽순처럼 널리 퍼져서 이를 이용한 웹사이트들의 운용도 늘어나면, 접근 불가능성도 함께 확산이 된다는 점이다. 또한, 온라인 학습 애플리케이션 등과 같은 새로운 세대의 애플리케이션들이 등장하면서 많은 문제가 발생하게 되는데, 이것들이 생성한 내용과 발행/편집기 인터페이스 두 군데 모두에게 접근성 지침의 준수가 요구되기 때문이다.
    1. 장애를 가진 사람들이 사용자 인터페이스를 조작하고 사용할 수 있어야 하는 것은 매우 중요하며, 그래서 W3C의 지침과 최신 표준 사항들을 따르면서 사용자 인터페이스의 품질과 접근성을 보장하는 요구 조건이 존재해야 한다.
    2. 모든 기술은 자기만의 접근성 지침이 마련되어 있어야 하며, 이러한 지침들은 공개적으로 사용될 수 있어야 한다: Macromedia Flash, Java, ActiveX, 등의 기술들은 최대의 접근성을 보장하기 위해 개발자들이 따라야 할 접근성 지침들을 갖고 있다.
  • WYSIWYG 웹 편집기들의 접근 불가성. 많은 웹 꾸림정보를 생성하는 도구들은 접근이 불가능하거나 혹은 “표준에 맞고 접근 가능한” 꾸림정보의 발행이 불가능하다. 과거 몇 년간, 세계 여러 곳에서 개발돼서 제정된 법 덕분에, 생성된 코드의 품질은 향상을 보여왔다. 이러한 법 제정은 몇몇 편집 도구들을 개발하는 회사들에 법에 명시된 수준에 따르는 새로운 버전의 도구들을 내놓을 것을 강제하였다.
  • 웹을 위해 생산된 웹 꾸림정보와 문서들의 접근 불가성. 이것은 많은 토론 항목 중에서 가장 많이 논의되었던 것들 중의 하나이다. WCAG 1.0으로, 많은 사람은 접근 불가성은 단지 HTML 코드에 한정된 것으로 단정하였었다. 하지만, 회사나 지방 자치단체에서 제공되는 서비스를 받기 위해서는 작성되어야만 하는 문서가 적절한 코드로 감싸져 있지 않고, 접근이 불가능한 PDF 문서와 같은 또 다른 기술들로 되어 있다면, 이런 경우는 어떠한가? 이것은 즉시 해결되어야만 하는 분명한 차별이며, 새로운 세대는 이러한 모든 웹 꾸림정보들의 접근성 문제를 어떻게 풀어나가야 할 것인지를 이해하는 것이 얼마나 중요한지를 깨달아야 할 것이다.
  • 웹 표준에 대한 부족한 지식. CMS 덕분에, 지금은 누구나도 손쉽게 웹사이트에 자신의 생각들을 올릴 수 있게 되었다. 비서 혹은 마케팅 간부에서부터 전문 “웹 정보 편집자”, “웹 저자”, 기타 등등. 어떻게 하면 적절한 markup을 사용할 것인지의 이해 없이도, 이런 “새내기 편집자들”은 CMS로부터 웹에 전달되는 꾸림정보를 생산할 수 있게 되었다. 하지만, 만약 이런 CMS가 올바른 markup 코드의 생성을 보장해 줄 수 없다면, 만약 WYSIWYG 편집기가 CMS에 정의되어 있는 스타일 쉬트들을 사용하지 않는다면, 이렇게 해서 생긴 마지막 결과물은 다른 사람들도 자신이 보는 것들과 같은 방식으로 볼 것이라는 잘못된 가정을 가지고서 “웹 꾸림정보 저자”의 것과 같은 PC 혹은 같은 브라우저의 똑같은 설정에서만 웹 페이지들을 제대로 볼 수가 있는 실수를 범하게 된다. 또한 우리는 앞 세대들에서 제기되었던, 올바르지 못한 문서 구조 등의 똑같은 문제들을 물려받게 된다.

[본문 내용으로]

미래의 세대: 진전된 표준화는 더 나아진 질적 향상을 의미하나?

이러한 문제 되는 여러 상황을 떠안고 있으면서도, 웹은 계속 진보하고 있으며, 가까운 미래에 우리는 WCAG 2.0, ATAG 2.0, XHTML 2.0, CSS 3.0, 그리고 World Wide Web 사용자 인터페이스의 접근성에 관한 ISO 지침(ISO 9241-151. Ergonomics of human system interaction – Part 151: Software ergonomics for World Wide Web user interfaces)을 기대할 수 있을 것이다. 이것은 세계가 더 향상된 품질의 웹 인터페이스들과 웹 꾸림정보, 그리고 장애를 가진 사람들이 웹 꾸림정보를 직접 생산해내고 또 이렇게 생산된 정보들에 접근이 가능하도록 하는 도구들을 필요로 한다는 뜻이다.

이러한 표준화 프로젝트에 참여하고 있는 사람들은 미래의 세계에서는 차별 없이, 많은 다양한 범위의 사람들 모두가 인터넷과 웹을 이해하고 사용할 수 있는 세상을 염두에 두고 있는 것이다.

우리가 미래의 차세대 웹 개발자들에게 얘기하고, 또 정의하고 싶은 점들은 무엇일까? 아래는 내가 꿈꾸는 미래의 웹이다.

  • 모두와 모든 것들을 위한 접근성. 국제적 안내 지침은 소프트웨어 (OS, 애플리케이션들, 소프트웨어 사용자 인터페이스, 등.), 하드웨어 , 터치스크린과 같은 다양한 기술들, ATM, 등의 접근성을 위한 표준을 세울 방침이다. 여기에는 국제적 표준 / 정부 지침에 병합되어야 하는 수많은 지침들이 존재하고 있다. 이것들이 제대로 적용되면 모든 사람에게 열려있는 제품들과 서비스들이 생산될 수 있을 것이다: 그려면 편집 도구들, CMS, 웹 애플리케이션들의 접근성, 그리고 기타 관련 기술들은 좋은 결실을 보게 될 것이다.
  • 문서를 위한 접근성. 웹에 존재하는 모든 문서는 모든 사람에게 읽혀질 수 있게 된다. 회사의 경우, 아직도 그들의 문서를 위한 접근 지침을 마련하지 못했다면 지금 당장에라도 시작해야 한다. 그렇지 않으면, 이미 법의 제정으로 모든 것들의 접근성을 요구받고 있는 회사들과의 경쟁에서 그들의 시장을 빼앗길 수밖에 없을 것이다.
  • 접근성에 관한 법 제정의 조화. 많은 회사는 이전 세기의 규약인 WCAG 1.0을 기준으로 하거나 영감을 얻은 자체 법률을 체액하고 있다, 새로운 WCAG 2.0이 수면 위로 떠오르고 있고, 또 새로운 ISO 표준들과 더불어, 나는 결국에는 국가적 법률들의 조화로 웹 접근성 도구들과 제품들에 올바로 적용되면서, 웹 접근성을 보장하고 비용도 더 적게 드는 데에 이바지할 수 있게 되기를 희망한다.

애플리케이션들과 웹 꾸림정보를 개발하면서 적절한 규약을 따르는 것은 당신을 “멋지게” 만들 뿐만 아니라, 당신을 진정한 웹 전문가로 만들어 줄 것이다.

[본문 내용으로]

감사의 말

이 문서를 편집하고 HTML 문서로 짜주신 Pam Berman씨에게 감사의 말을 전한다.

[본문 내용으로]

따옴 – A Journey Through Accessibility

꼬리표:

관련된 주제의 글

댓글을 남겨 주세요