생성 캔버스는 누가 설명하는가
p5.js의 describe()와 textOutput(), W3C의 텍스트 대체 원칙을 바탕으로 생성·인터랙티브 캔버스의 설명을 부가 기능이 아니라 작품 리비전과 함께 움직이는 창작 책임으로 살핀다.
브라우저 안에서 수천 개의 점이 흐르고, 관객의 움직임에 따라 색과 밀도가 달라진다. 화면을 보는 사람은 변화의 방향과 속도, 선택 이후의 결과를 한꺼번에 읽는다. 그런데 다른 감각 경로에서 이 작품은 그저 하나의 canvas로 남을 수 있다. 이미지는 계속 움직이는데 작품의 상태와 의미를 전할 문장은 멈춰 있는 셈이다.
이 장면만 봐도 접근성을 전시 막바지에 설명문 하나 덧붙이는 일로 다룰 수 없는 이유가 드러난다. 생성·인터랙티브 작품은 완성된 이미지 한 장이 아니라 규칙과 데이터, 입력에 따라 달라지는 관계로 존재한다. 설명도 고정된 캡션 한 줄이 아니라 작품의 현재 상태와 함께 바뀌어야 한다. 무엇이 보이는지만큼이나 무엇이 달라졌는지, 그 변화가 관객에게 어떤 행동이나 해석을 요구하는지까지 누군가 결정해야 한다.
화면을 그리는 코드와 설명하는 코드
p5.js는 캔버스를 설명하기 위한 두 함수를 제공한다. 공식 문서에 따르면 describe()는 작성자가 넣은 문장으로 캔버스의 screen reader-accessible description을 만든다. LABEL을 쓰면 설명이 캔버스 옆에 보이고, FALLBACK을 쓰거나 표시 방식을 생략하면 screen reader에만 보이는 기본 모드가 적용된다.
textOutput()은 조금 다른 일을 한다. 캔버스의 도형을 바탕으로 일반 설명, 도형 목록, 도형 표를 웹페이지에 추가한다. 일반 설명에는 캔버스 크기와 색, 도형 수가 들어가고, 목록은 도형의 색·위치·면적을, 표는 좌표까지 포함한다. 공식 문서는 textOutput(LABEL)이 screen reader에 불필요한 중복을 만들 수 있으므로 개발 중에만 사용하라고 안내한다. FALLBACK은 여기에서도 기본 모드다.
두 함수는 출발점을 마련하지만, 호출했다는 사실만으로 작품을 충분히 설명했다고 볼 수는 없다. 자동으로 생성된 목록은 파란 원이 오른쪽 위에 있고 화면의 일정 면적을 차지한다는 사실을 말할 수 있다. 하지만 그 원이 관객의 선택인지, 센서 오류인지, 데이터 범주의 이동인지까지 결정하지는 않는다. 기하학적 사실과 작품의 의미 사이에는 작가와 설명 작성자, 접근성 검토자의 판단이 필요하다.
사람이 직접 쓰는 설명도 안심할 수는 없다. 작성자가 describe()에 해석을 많이 넣으면 작품의 불확정성을 하나의 정답으로 고정할 수 있다. 설명은 이미지를 말로 복제하는 작업이 아니라, 현재 장면을 이해하는 데 빠지면 안 되는 관계와 아직 열어 두어야 할 해석의 경계를 정하는 작업에 가깝다.
프레임이 아니라 상태를 설명한다
생성 작품의 모든 프레임을 문장으로 옮길 수는 없고, 그렇게 할 필요도 없다. 계속 바뀌는 수치와 좌표를 그대로 읽어 주면 작품의 리듬보다 알림의 양이 앞설 수 있다. 설명이 갱신되어야 할 순간은 화면의 모든 변화가 아니라 관객의 이해나 다음 행동이 달라지는 의미 있는 상태 전환이다.
관객이 선택하기 전과 후, 데이터가 새로운 범주로 넘어간 순간, 작품이 일시 정지하거나 오류 상태에 들어간 장면, 주 경로가 작동하지 않아 축소된 화면으로 전환된 경우가 그런 경계가 될 수 있다. 각 상태에는 현재 보이는 핵심 관계, 그 상태를 여닫는 사건, 연결된 설명 문장, 이전 문장을 회수하는 규칙이 함께 있어야 한다. 화면은 새 장면으로 넘어갔는데 설명은 이전 선택 결과를 말한다면, 설명이 존재해도 현재 작품을 전달하지 못한다.
여기서 중요한 것은 설명의 길이보다 리비전의 관계다. 작품의 코드와 데이터, 상호작용 규칙이 바뀌면 설명도 다시 검토해야 한다. 브라우저나 p5.js 버전, 표시 방식, 언어, 전시장 환경이 달라졌을 때 이전 관찰을 그대로 현재 증거로 사용할 수도 없다. 설명문 파일만 보존하고 어느 작품 상태와 연결되었는지 남기지 않으면 재설치 때 같은 접근 경로를 복원하기 어렵다.
동적 작품의 설명 기록에는 최소한 현재 작품 리비전, 설명이 달라지는 시각 상태, 정확한 문장 리비전, 노출 방식, 확인한 환경과 확인하지 못한 범위가 함께 남아야 한다. 이것은 복잡한 행정 양식이 아니라 오래된 문장이 현재 화면을 대신하는 일을 막는 제작 기록이다.
접근성은 미학을 평평하게 만드는 일이 아니다
W3C의 WCAG 2.2 비텍스트 콘텐츠 해설은 시각·청각 콘텐츠에 텍스트 대안을 제공한다는 기본 방향을 제시한다. 동시에 특정 감각 경험 자체가 목적이라면 그 비텍스트 콘텐츠를 식별할 수 있는 설명을 제공하는 경계를 둔다. 이 문서는 WCAG 이해를 돕는 해설이며, 그 자체가 개별 작품의 적합성 판정서는 아니다.
미디어아트에서 이 구분은 중요하다. 화면의 모든 입자와 색을 빠짐없이 나열한다고 작품의 감각이 보존되는 것은 아니다. 반대로 “말로 옮길 수 없는 경험”이라는 이유로 아무 설명도 제공하지 않으면, 어떤 작품이 있고 무엇이 변하는지 확인할 출발점까지 사라진다. 설명은 감각을 평평하게 번역하는 자막이 아니라, 작품에 들어갈 수 있는 다른 문을 만드는 일이어야 한다.
색으로 상태를 구분하는 작품도 같은 질문을 만난다. W3C의 색 사용 해설은 색을 정보 전달, 행동 표시, 반응 유도, 시각 요소 구분의 유일한 시각 수단으로 쓰지 말라고 설명한다. 생성 캔버스에서 선택 상태를 색만으로 바꾼다면 형태, 경계, 위치, 짧은 문구처럼 같은 의미를 전달하는 추가 단서를 함께 설계할 수 있다. 다만 이 원칙을 적용했다는 사실만으로 screen reader 경로나 전시 전체의 접근성이 자동으로 완성되지는 않는다.
접근 가능한 설명의 목적은 작품의 모호함을 없애거나 감상법을 하나로 고정하는 데 있지 않다. 오히려 관찰 가능한 사실, 작가가 승인한 해석, 아직 확인하지 못한 부분을 구분함으로써 작품이 가진 여백을 더 정직하게 보존한다. 설명이 너무 확정적이면 관객의 해석을 닫고, 너무 추상적이면 현재 장면을 찾는 데 도움이 되지 않는다. 이 사이의 긴장을 조절하는 일도 창작의 일부다.
설명의 저자는 누구인가
자동 도형 목록은 개발자가 현재 캔버스 구조를 점검하는 데 유용할 수 있다. 작가는 어떤 관계가 작품의 핵심인지 결정하고, 설명 작성자는 그 관계를 다른 감각 경로에서 읽히는 문장으로 다듬는다. 접근성 검토자는 문장이 실제 노출되는지와 최신 상태를 가리키는지 확인하며, 전시 운영자는 재시작이나 오류 뒤에도 현재 설명을 회수할 경로를 유지한다. 이 역할들이 한 사람에게 모일 수도 있지만 책임의 층까지 합쳐지는 것은 아니다.
화면 옆에 설명이 보인다는 사실과 특정 screen reader에서 읽힌다는 사실은 별개의 관찰이다. FALLBACK을 요청했다는 코드 기록도 실제 노출과 이해를 대신하지 않는다. 개발 화면과 접근성 트리, assistive technology, 관객 경험에서 확인되는 사실은 서로 다르다. 한 층의 성공을 다른 층의 성공으로 넓혀 말하지 않아야 한다.
생성 캔버스의 설명은 완성 뒤에 붙는 부록이 아니다. 어떤 상태를 작품의 의미 있는 단위로 볼지, 무엇을 자동으로 추출하고 무엇을 사람이 써야 할지, 변화한 화면과 오래된 문장이 어긋났을 때 어디서 다시 연결할지를 정하는 두 번째 저작 과정이다. 화면을 만드는 알고리즘이 작품의 형식을 쓴다면, 설명의 리비전과 갱신 규칙은 그 작품이 다른 감각 경로에서도 현재형으로 존재하게 만든다.
결국 물어야 할 것은 “설명이 있는가”보다 “그 설명은 지금 어떤 작품 상태를 가리키는가”이다. 어느 상태를 가리키는지 답할 수 있어야 캔버스가 보는 사람에게만 열린 표면에 머물지 않는다. 설명은 이미지를 대신하지 않지만, 작품이 사라지지 않고 다른 방식으로 만날 수 있게 하는 또 하나의 매체가 된다.