[사이드 프로젝트] 웹 접근성 검사 도구 제작기

사이드 프로젝트를 하나 만드려는데 좋은 아이디어가 떠오르지 않았다. 흔한 게시판이나 쇼핑몰, 영화 사이트가 아닌 독특하거나 난이도가 있는 프로젝트를 원했다. 생각이 늘어지다가 gpt한테 물어보면 어떨까 생각했다.역시 gpt다. 하나 같이 좋은 아이디어들 뿐이다. 그 중

전에 언급하였듯 파일을 업로드하면 바로 결과를 얻을 수 있는 간단한 ui를 원했다. 떠오른 것은 구글이었다. 구글의 검색창처럼 빈 화면 가운데에 업로더만 있으면 심플하지 않을까. (대신 너무 허전하니깐 헤더만 살짝 추가하는 걸로...)그 후 검사 버튼을 누르면 좌측엔

계획은 이러하였다. 파일을 텍스트로 읽는다.(html의 경우) htmlparser2 패키지로 문자열의 코드를 DOM 형식의 객체로 파싱한다.validator를 직접 제작하고 검사 결과에 따른 클릭 함수와 스타일링을 DOM 형식의 객체에 담아준다.외부 Highlighte

HTML Highlighter에서 줄 바꿈은 간단하다. 자식 노드가 존재하고 그 노드가 tag라면 줄 바꿈을 해주면 된다. 들여쓰기가 까다롭다. 우선 자식 노드가 tag라면 들여쓰기를 하는데 이때 tabStack을 1씩 증가하고 그만큼 들여쓰기를 해준다.닫는 태그의 경

이제 검사 후 문제가 있는 코드에 색깔 처리를 해주고 클릭 이벤트를 주어야 한다. 코드를 검사한 뒤 그 결과를 파싱된 코드 객체에 담아주면 결과에 따라 하이라이트된 코드 노드를 만들 때 색깔 처리와 클릭 이벤트까지 같이 적용하는 방식.그런데 가만 생각해보니 그렇게 되면

난이도가 너무 높았던 걸까. 혹은 현실성이 부족했을까. 웹 접근성 검사는 사실 사람이 어떤 부분을 신경 써야 할지 인지한 상태로 직접 체크하는 편이 훨씬 효율적일 수 있다. 물론 그마저도 프로그램을 제작한다면 편리하겠지만 제작 난이도가 매우 높고 웹 접근성 검사란 것

CSS validator가 비교적 쉬운 것 같지만 모든 선택자의 rule을 검사해야 하기에 헷갈리는 부분이 많았다. 특히 초반에 직렬화 문제로 대부분의 값을 Object.values로 처리하다 보니 코드 가독성도 좋지 못했다.(↑/validator/css/index.t

지금까진 태그와 텍스트로만 구분하였다. 그러다 보니 주석 또한 텍스트로 인식하는 일이 일어났다. 이 경우 어떤 문제가 있냐면, 텍스트는 XSS 검사를 하고 있는데 태그를 주석 처리한 경우 해당 주석이 텍스트로 인식되며 XSS 검사에 걸리는 것이었다. 이를 방지하고자 그

그동안 외부 프로젝트를 진행하느라 제쳐두었던 사이드 프로젝트 '웹 접근성 검사 도구' 배포를 했다. 사실 정적 웹 사이트는 빌드 후에 버킷에 올리기만 하면 돼서 간단하다.우선 AWS 홈페이지에서 S3를 찾아 들어간다.그 다음 버킷을 생성해 준다.버킷명을 정해주는데, 이