Blue Links

구글에서 제공하는 서비스로 Blue Links 라고 불린다.

지메일 내용에 날짜, 전화번호, 주소, 이메일 주소가 자동으로 인식되어서 <a>링크가 걸리는 현상이다. 



해결방안

1. 링크를 막는 메타 태그 사용

  • <head> 태그에 들어가야함.
  • 하지만 정확한 해결책인지 확실하지 않음.


메타태그
<meta name="format-detection" content="address=no">


2. "Zero Width No-Break Space"문자 (& # 65279) 또는  "Zero WidthSpace"문자 (& # 8203) 사용


엔티티코드 예시
<p>&#65279;서&#65279;울&#65279;특&#65279;별&#65279;시&#65279; 서&#65279;초&#65279;구&#65279; 신&#65279;반&#65279;포&#65279;로&#65279;</p>



3. <a>요소에 스타일적용.

  • <a> 요소를 지정해서 사용하되 사용자가 육안상으로 봤을때 텍스트로 인식하게 하는 방식.
  • 인라인 형식으로 들어갈 경우 htref 속성을 작성하지 않는다.


<a> 인라인방식
<a style="color: #333; text-decoration: none; cursor:text;">서울특별시 서초구 신반포로</a>


내부, 외부 스타일 방식
.link > a {
    color#333;
    text-decorationnone;
    cursor: text;
}



문장 줄바꿈의 문제


디자인때문에 줄바꿈을 하려고 <br>요소를 사용하는 경우가 많다.



이때 생기는 문제점이 하나 있다.

<br>을 사용해 줄바꿈을 하게 되면 스크린리더기에서 문장을 이어서 읽어주지 않는다.





예를 들면

화면
이미 가입된
이메일 입니다.

코드
<p>
이미 가입된<br>
이메일 입니다.
</p>

스크린리더기 음성지원
'이미 가입된' 

까지만 읽고 멈춘다.



사용자가 다음 문장을 읽을라면 사용자가 직접 다음으로 넘기는 행동을 취해야지만 

'이메일 입니다.'

를 마저 읽어준다.



위와같은 상황을 보면 단순히 눈에 보이는 혹은 디자인 때문에 <br>요소를 사용해서 줄바꿈을 하는것은 옳지않다.





사실

줄바꿈을 위해 사용하는 <br>요소는 웹접근성에 위배되는 사항은 아니지만

실제로 스크린리더기를 사용하는 사용자의 접근성을 높이려면 <br>을 사용해서 줄바꿈의 하는 형태는 좋지 않다고 판단된다.




해결방법

CSS를 속성인 white-space 사용하면 문제를 해결할수 있다.

상황에 따라 아래 2가지의 값을 사용하면 될것으로 판단된다.

  • white-space: pre-wrap;
  • white-space: pre-line;

( + 줄바꿈할 문장을 다른요소로 묶어서 display: block;을 한다던가 <p>요소를 사용해 묶어도 문장을 이어서 읽어주지 않는다. )




참고

MDN( white-space )

<br>사용 스크린리더  | 웹접근성연구소

Button[type="submit"]    vs   input[type="submit"]



버튼요소에 대해 생각하게된 상황은 이러하다



새롭게 개편된는 페이지 코드를 작성중이였다.



상황 1


백단개발자

: <form> 안에서 왜 <button> 태그 사용했어요?


: 왜요? 사용하면 안되나요? 버튼역할이 submit 이면 되잖아요.


백단개발자

: 넹..



상황 2


아이폰 기기에서 사파리앱으로 사이트 접속후 PC버전을 클릭했을때 모든 input요소들이 웹킷에서 제공하는 기본스타일들이 (둥근 테두리값, 그림자 효과) 적용되어 있다.


그래서

기본 스타일이 적용되고 있는 input(모든타입 전부), textarea 요소를 확인후  

-webkit-appearance: none; 과 border-radius: 0;   값을 적용해 문제를 해결을 했다.



그러나 

모든 input에 적용했더니 PC 크롬브라우져에서 기본 체크박스나 라디오도 스타일을 사용하는 부분도 스타일이 사라지는 문제 발생. 

이것은 나의 잘못!!!  생각없이 한 수정작업이였다.


그래서 

기본스타일이 먹는 곳을 찾아 확인해보니 작업중인 사이트에선 input[type="submit"]에서만 이러한 현상을 보여서 선택자로 잡아서 최종해결.


그리곤 

나는 이슈 댓글로 앞으론 input[type="submit"] 대신 button[type="submit"]을 사용하겠다고 남겼다.

왜? 어차피 같은 역할을 할것이고 위와 같은 이슈가 벌어지지 않기 때문이다. 


( 참고로 위의 이슈에 관해서는 작업중인 사이트에 해당되는 상황이므로 공통적인 이슈가 되진 않는다. )



이 댓글을 보신 


개발팀장님

: input[type="submit"]  대신  button[type="submit"]을 쓰려는 이유는?


: button의 기본은 submit이기도 하고 보이는 스타일이 버튼이라서... 

: input으로 사용해야하는 이유가 따로 있나요?


개발팀장님

: button은 범용으로 쓰기엔 좀 문제가 있었다는 기억이 있기도하고 ie문제 어쩌고 하는 얘기도.......

: input과 button의 동작이 좀 달랐던 기억이라 안 쓰는 편입니다.


: 음.. 한번 더 확인해볼게요..


개발팀장님

: button을 채택하려는 이유가 명확하게 있는지 물어본 거예요.

: button 말고 input 쓰세요 는 아님

: 혹시 정보 더 있으면 저도 좀..

: 저런 결정사항은 가급적 근거를 제시해주세요. 나중을 위해서, 다른 사람을 위해서....


                                


이러하여 난 구글링을 시작했다...




일단,  submit할때 <input>, <button>의 기능차이는 없다.




문제파악 1.


팀장님 말씀대로 IE에서 이슈가 존재했다. 

      • https://www.peterbe.com/plog/button-tag-in-IE  

문제파악 2.


이전에는 IE8까지 문제가 있었으나

      • https://developer.mozilla.org/ko/docs/Web/HTML/Element/button 

하단에 참고 내용보면  'This bug has been fixed in IE8.'  이라고 하니 IE8에선 수정된것 같다.


문제파악 3.


그러면 IE7이하 버전은 문제가 되는것으로 보인다. IE7은 너무 하위버전이긴 하지만

      • https://www.w3schools.com/tags/tag_button.asp  

여기서 팁노트를 보니 <form>에서 submit할땐 <button>보단 <input type="submit">을 사용하는게 좋다고한다.

하지만 내생각에는 button의 value값을 사용하지 않은 경우라면 <button type="submit"> 사용해도 무리는 없어 보인다.


근데 혹시 모르니 다음부턴 <form>전송할때는 <input type="submit"> 사용하는게 좋을것같다는 판단이 들었다.





최종

  1. <form>전송할때는 <input type="submit"> 사용.
  2. 그 외에 js로 동작처리를 하거나 단순한 button의 기능을 가진것은 <button>을 사용으로 결론을 내렸다.


왜?

<input>에 비해 <button>의 경우는 이미지를 사용한 버튼 사용할수 있고 다른 태그들을 사용할수 있어서 스타일링이 다양해 질수있기도 하고 

더 시멘틱하다고 생각하기 때문에 <button>사용하는 방향으로 작업하는것이 좋을것같다. 

    • http://jsunnylab.tistory.com/38
    • http://webdir.tistory.com/421
    • http://nuli.navercorp.com/sharing/blog/post/2038




+ Recent posts