La W3C dentro de su estructura base de reporte de evaluación de accesibilidad web en conformidad con la Web Content Accessibility Guidelines (WCAG) 2.2, sugiere que una correcta evaluación lleva múltiples herramientas automáticas y una evaluación manual para verificar el correcto funcionamiento del sitio, hablando específicamente de las reglas de accesibilidad que la misma página web debe tener escritas en sus políticas de accesibilidad.

Tomando como punto de partida la lista de herramientas para probar accesibilidad de la W3C, filtraremos las automáticas, gratuitas y que se pueden utilizar directo en el navegador.

Los datos obtenidos fueron obtenidos verificando la accesibilidad de la misma página web, la página de inicio del Sisdai, para poder observar las diferencias entre cada herramienta. La muestra se tomó entre el 10 y el 12 de julio del 2024.

Accessibility checker auditing tool

Es una herramienta de una empresa privada de Estados Unidos de América, utilizada para escanear una página web y revisar la accesibilidad en base a los estándares WCAG 2.1 level AA que también revisa estándares y políticas de accesibilidad de algunos países (no aplica a México).

El error crítico que encuentra ésta herramienta es de legibilidad en los enlaces que se utilizan en los pies de página. Los enlaces tienen un área de interacción muy chica, de 18px, comparado contra los 24px mínimos que se requieren. También ambos footers tienen errores de contraste que en éste caso en particular son difíciles de solucionar porque son colores de identidad institucional que no pueden modificarse sin antes modificar el manual de identidad para cada institución.

También muestra una sección de varios los elementos que deben ser revisados manualmente para verificar si cumplen o no los estándares de accesibilidad.

Un problema de ésta herramienta es que no deja hacer muchos análisis por día y verifica de vista en vista, lo que hace improbable utilizar la versión gratuita para sitios web muy extensos, se necesitaría demasiado tiempo.

AEL Accessibility Checker (AAC)

Es una herramienta de una empresa privada de la India con la que se puede evaluar la accesibilidad de una página web, pero no dan nada de información a simple vista, te pone una calificación sobre cien y para obtener detalles es necesario solicitar una consulta gratuita proporcionando un correo electrónico.

IBM Tools Equal Access Accessibility Checker

Es una extensión de código abierto creada por IBM que detecta problemas en la accesibilidad de sitios web. También proporciona ayuda descriptiva de los errores, en donde se encuentran y cómo solucionarlos.

Esta herramienta se puede configurar para que verifique contra distintos criterios de accesibilidad. De manera predeterminada se encuentra seleccionado el criterio IBM Accessibility 7.21, que cumple con las reglas de la WCAG 2.1 y se le agregan otros criterios requeridos por IBM

En el análisis con ésta herramienta se encontraron para la página de inicio del Sisdai, múltiples errores de elementos sin landmarks, que requieren que se reestructure la página para agregarlos. También muestra el error de que por página solo debe existir un único footer, que para éste caso teniendo dos, deberíamos especificar el aria-label de cada uno.

No salen los errores de falta de contraste ni espacio de interacción de los enlaces en los pies de página!!… pensando bien, supondré que es porque primero se espera que se corrijan los errores de etiquetado para cada pie de página.

Achecker +

Creada por Cantan Group, una empresa Canadiense, la herramienta AChecker evalúa de forma predeterminada si los elementos de una página web cumplen con los criterios de accesibilidad WCAG 2.0 para sitios web, también se puede seleccionar qué criterios de evaluación se requiere analizar.

El primer error que encuentra ésta herramienta es de legibilidad en los enlaces que se utilizan en los Pies de página por falta de espacio clickeable.

El segundo error es acerca del video que se utiliza de fondo en la primer sección de presentación de la página, agregando el mensaje de que el video no cuenta con subtítulos, error curioso porque el video es decorativo, más bien no deberíamos utilizar video… pero… decisiones de arriba… cómo se arregla la cadena de mando? La sugerencia es agregarles la propiedad aria-hidden y cambiarles el rol por uno genérico como role=”presentation”.

Esta herramienta también muestra una sección de varios los elementos que deben ser revisados manualmente para verificar si cumplen o no los estándares de accesibilidad.

Squidler

En su página web se puede ingresar la URL de un sitio web para verificar su accesibilidad y algunos otros tipos de error. Squindler utiliza a su vez Axe-core para probar los criterios de accesibilidad WCAG 2.0 y 2.1.

No están muy bien definidos los errores, no especifica el elemento en el que se encuentra ni sugerencias para arreglarlo… personalmente no me gustó esta herramienta, pero más o menos pude interpretar los errores que mostró la herramienta.

El primer error habla de un enlace roto, pero revisando manualmente el sitio y con otras herramientas no aparece ningún enlace roto, lo que me hace dudar que realmente exista.

El segundo error es el mismo que reportó la herramienta de IBM, no debe existir más de un pie de página en un sitio web.

El tercer error parece ser el que reportó la herramienta de IBM de los elementos flotantes que no tienen un landmark definido.

AChecker

Es un validador de accesibilidad en línea que tienen algunas opciones de configuración del criterio de accesibilidad a evaluar, pero la versión más actual es la WCAG 2.0 que estaba obsoleta con los criterios que requería para analizar el sitio, así que me lo salte, porque pues no me sirve para analizar.

QualWeb

QualWeb es un sitio web para evaluación automática de accesibilidad. Utiliza los criterios de WCAG 2.1 y las reglas de ACT Rules.

Solo muestra un error de que existen algunos elementos con el tamaño tipográfico mal declarado, uy… este va a ser difícil de arreglar, hay que verificar que todo el contenido este declarado en unidades relativas para que pueda escalarse adecuadamente por las personas que visiten el sitio. Bueno, al menos la herramienta también muestra una lista de los elementos en donde encontró el error.

Axe DevTools

Es una extensión gratuita para Chrome que evalúa los elementos de una página web para probar los criterios de accesibilidad WCAG 2.1 AA. Para configurarse se debe pagar una suscripción.

Tiene varias opciones de pruebas interesantes, pero para todo te pide suscripción.

Analizando la página de inicio del Sisdai con la versión gratuita no muestra ningún error! vivaa! somos unos genios! jejeje.

Includia Accessibility Checker

Es una extensión de Google Chrome para la evaluación de la accesibilidad. Dice estar basada en la última versión de la WCAG. Que no sabría cual es porque supongo que depende de la fecha de actualización de la extensión… pero en ningún lado dice explícitamente la versión, preferiría tenerlo claro.

Ésta herramienta detecta dos errores, los mismos que la herramienta de IBM. Primero, existen elementos fuera de landmarks y segundo, existen dos footers y no está etiquetado ninguno de que información contiene.

RAMP Web Accessibility Tools

RAMP es la página web de una empresa de Estados Unidos que se dedica a la accesibilidad web. La parte gratuita de este sitio web, sirve para verificar la accesibilidad de un sitio, conforme los criterios de la WCAG, no encuentro en que versión ni nivel estarán probando

Escaneando con la versión gratuita y sin cuenta simplemente dice que no se encontró ningún error y no da ningún detalle a menos que se cree una cuenta.

Silktide accessibility checker

Silktide es una extensión gratuita que se instala en Google Chrome, tiene múltiples opciones de revisión, entre ellas el ‘Accessibility checker’ que dice validar la accesibilidad de los elementos de la página web con WCAG 2.0, 2.1 y 2.2.

Señala un solo error por tener un video sin subtítulos asociados. Pero otra vez, en éste caso que el video no es informativo, es decorativo y ni siquiera tiene audio ni texto… es una mala decisión poner el fondo de la presentación así y me lo van reafirmando las herramientas, quitalo, quitalo, quitalo, dicen… pero ojalá escucharan los mismo las personas encargadas de tomar la decisiones.

Sa11y

Es una herramienta de la universidad metropolitana de Toronto. Puede funcionar desde el bookmark del navegador ó se puede instalar en un sitio como plugin para wordpress o joomla. Funciona un poco a la vez como menú de accesibilidad y como validador de accesibilidad. Utiliza como referencia la versión WCAG 2.1 AA.

Los errores que esta herramienta encuentra son de contraste en textos que están declarados como de solo lectura, es decir, los que no son visibles pero que si se pueden escuchar con lectores de pantalla, jeje, obviamente si no se deben ver no importa su contraste. Ningún otro error es detectado por esta herramienta.

ARIA DevTools

ARIA DevTools es una extensión para Google Chrome que muestra visualmente la estructura del sitio web de la manera en que los lectores de pantalla leen la estructura y elementos por los ARIA rol que se utilizan.

Aaaaaammmm no se ve muy seguro por el icono del pirata.. Da un poco de miedo de instalar, pero ya que te animas se ve muy clara la estructura y los errores que puede tener.

No da una lista de errores, alertas ni sugerencias, solo puede utilizarse para análisis manual de la estructura del sitio.

Lighthouse

Lighthouse es una herramienta open-source que revisa el rendimiento, accesibilidad y SEO en páginas web. Utiliza reglas de mejores prácticas y accesibilidad WCAG 2.0 2.1 y 2.2 nivel A y AA.

Puede leerse la forma de puntuación de accesibilidad de lighthouse para revisar a más detalle la evaluación.

El primer error que detecta es por la falta de área clickeable en los enlaces del footer. El segundo error es dado por la falta de subtítulos en el video decorativo, que no tiene ni audio, pero que no debería haberse utilizado de fondo… ojalá, ojalá, algún día se cambie simplemente por una imágen estática.

También muestra una lista de elementos que necesitan evaluarse manualmente para saber si cumplen los criterios de accesibilidad.

wave

Es una extensión que puede instalarse en múltiples navegadores desarrollada por la universidad de Utah.

No se encuentra en la lista de herramientas para validar accesibilidad de la W3C, pero la universidad que creo esta herramienta es una gran referente del tema, así que la inclui como pilón.

Además que al final de la lista en la página web de la W3C incluyen un texto que dice que no evaluaron la veracidad de ninguna herramienta y que la información que ponen de cada herramienta es proporcionada por sus creadores.

Con ésta herramienta obtenemos un error y un par de alertas. El error da por el bajo contraste del texto de solo lectura. La primer alerta es por agregar la etiqueta <noscript> que al parecer ya no es requerida, y la segunda por la falta de subtítulos en el video decorativo, que comienzo a odiar un poco, pero que como sugerencia nos comentaron que podía agregarse el aria-hidden y el rol presentation; y como mejor sugerencia, no utilicen videos decorativos de fondo con autoplay repeat mute... no solo dio errores de accesibilidad, también para celulares fue un tema.

Como conclusión, solo puedo decir que existen múltiples herramientas, todas aportan cosas diferentes, necesitamos encontrar una estrategia para probar la accesibilidad que ajuste con los criterios de las WCAG que el sitio o aplicación que estemos desarrollando esté intentando cumplir para acercarnos más a que esto suceda.

En lo personal, me gusta utilizar la combinación de WAVE Browser Extensions con la de IBM Equal Access Accessibility Checker, por que además se pueden utilizar en varios navegadores y que como desarrolladora de front-end estoy acostumbrada y necesito ver y analizar los sitios en varios navegadores, resoluciones y dispositivos distintos.

P.D. disculpen las fotos, ya tendré tiempo de tomar propias :}

Hace algún tiempo me encontré con un reporte de accesibilidad analizando un millón de páginas web que publicó WebAIM (uno de los grandes referentes del tema en Estados Unidos) https://webaim.org/projects/million/

En este reporte aparecen, entre otras cosas, los seis errores más comunes de accesibilidad y la verdad me sorprendió la lista… son cosas super simples que … porque olvidamos?

Si no tenemos tiempo de leernos la documentación de accesibilidad y sensibilizarnos con el tema, al menos podemos colaborar a la vida evitando caer en el mismo error una y otra vez.

Los errores más comunes que debemos evitar 🫡

1. Tener bajo contraste de texto (81.0%)
2. Utilizar imágenes sin texto alternativo (54.5%)
3. No etiquetar correctamente los campos de entrada (48.6%)
4. Tener enlaces vacíos!! (44.6%)
5. Tener botones vacíos! (28.2%)
6. No agregar atributos de lenguaje al documento (17.1%)

1. Verificar el contraste del texto

Por lo general este error lo resuelve el equipo de diseño. Al seleccionar la paleta de color que utilizará el sitio o sistema de diseño, deberán asegurarse que el contraste sea apropiado para la lectura.

Al equipo de desarrollo simplemente nos pasan una lista de hexadecimales que utilizar… aun así… si notas algo raro, no olvides reportarlo a tu diseñadora favorita… que normalmente en el área de diseño no tienen QA, no se porque! de que privilegios gozan ?! u.u

2. Agregar texto alternativo a las imágenes

Si cuentas con un equipo de contenido (quienquiera que esté escribiendo la información que se verá en pantalla), debería de existir un documento en donde para cada imagen que se requiera poner en pantalla, se agrega el texto alternativo que ésta debe de tener, incluso si va vacío como el caso de las imágenes decorativas.

El equipo de desarrollo debe cerciorarse de que toda etiqueta <img> de imagen lleve siempre el atributo alt con o sin contenido, como se haya especificado por el equipo.

<img alt="texto alternativo">

3. Etiquetar los campos de entrada

Dependiendo del diseño, hay distintas formas en las que se puede etiquetar un campo.

• Cuando el campo de entrada tiene visible la etiqueta de nombre, unicamente es importante recordar ligar ambos elementos con el for del <label> y el id del <input>.

<label for="nombre">
  Nombre completo
</label>
<input 
  id="nombre" 
  type="text" 
  placeholder="Ejemplo: Alma Leticia"
/>

• Cuando únicamente se ve el campo de entrada, puede utilizarse el atributo aria-label en la etiqueta del campo <input>, selector <select> o área de texto <textarea> para agregarle la información del nombre al campo.

<input 
  aria-label="Nombre completo" 
  type="text" 
  placeholder="Ejemplo: Alma Leticia"
/>

4. Agregar contenido a los enlaces

Parecido que con las imágenes, es un trabajo en equipo, es necesario que quien escriba el contenido siempre piense que texto significativo debe verse cuando se agrega un enlace, mientras que el equipo de desarrollo debe cerciorarse de que no se escriba nunca una etiqueta de enlace <a> ni sin enlace href=”” ni sin contenido > … <

<a href="enlace"> texto significativo </a>

5. Agregar contenido a los botones

Tanto el equipo de diseño como el equipo de contenido están envueltos en resolver que se verá y que se escuchará en un botón.

• Para un botón sencillo <button> con texto, nada más es verificar que funcione y se vea como se debe leer, la acción a realizar por la persona usuaria.

<button type="button"> Acción a realizar </button>

• Cuando un botón contiene texto y pictograma, el texto debe decir qué acción se va a realizar, mientras que el pictograma debe ocultarse auditivamente mediante el atributo aria-hidden que se incluye en el elemento que contenga el pictograma, en éste ejemplo un <span>.

<button type="button">
  Acción a realizar
  <span class="pictograma" aria-hidden="true"> :} </pictograma>
</button>

• Para un botón que contiene únicamente el pictograma, se mantiene el aria-hidden en el <span> del pictograma y se agrega un aria-label al elemento botón <button> para especificar la acción a realizar.

<button 
  type="button"
  aria-label="Acción a realizar"
>
  <span class="pictograma" aria-hidden="true"> :} </pictograma>
</button>

6. Agregar atributo de lenguaje al documento HTML

Es un atributo que la mayoría de los frameworks ya traen siempre escrito, aunque como la mayoría están en inglés, habrá que cambiarle este atributo a la página al español.

El lenguaje general del documento se declara en la etiqueta raíz de HTML

<!DOCTYPE html>
<html lang="es-mx">

Cuando existen fragmentos de la página en otro idioma es necesario agregarle el atributo lang a la etiqueta que contenga el texto en particular.

<span lang="en">hello</span>

— Con esto solucionamos los errores más comunes. 🎉

Otras recomendaciones generales para mejorar accesibilidad mediante el código 🤓

• Utilizar HTML semántico.
• Agregar un enlace para ir al contenido principal, al inicio de la página antes de la navegación y cabecera.
• Agregar un título a cada página en el <header>.
• Organizar la estructura principal del sitio con etiquetas de región como <nav>, <header>, <main>, <footer>, <section>, <article>, <aside>
• Verificar que solo exista un <main> por vista.
• Utilizar solo un <h1> por página.
• No brincar entre jerarquías de títulos, después del <h1> el siguiente título que necesitemos debe ser un <h2>.
• Para formularios complejos, utilizar el <fieldset> y <legend> para agrupar campos de información en secciones.

Escucha la página

El orden de la lectura es igual al orden de la estructura del código, puedes intentar escuchar la página una vez que esté terminada para verificar que se comprenda, también ayuda a corregir la ortografía y puede ayudar en general a mejorar la estructura.

Navega la página

Revisa que todos los elementos interactivos tengan estado de enfoque y que el orden en el que navegas entre uno y otro, utilizando el tabulador, sea el esperado. Puedes navegar el sitio con el teclado para verificarlo.

Verifica la accesibilidad básica con herramientas automáticas 🦇

Existen un montón de herramientas que se pueden instalar en el navegador para verificar la accesibilidad.

De mis favoritas serían las de IBM y la de Google Chrome

• IBM Tools Equal Access Accessibility Checker
• Lighthouse

También me gusta mucho una enfocada particularmente los aria y landmarks, para ver la estructura del sitio.

• ARIA DevTools

Y para validación del código fuente durante la etapa de desarrollo, se puede agregar una extensión de Visual Studio Code

• axe Accessibility Linter

Descansa🌟

La mayor parte de los errores los cometemos cuando estamos desveladas, presionadas, sin comer, sin café (o lo que sea que te de pila) …. la vida no se trata solo del trabajo! pero si ya lo vamos a hacer hay que hacerlo bien :}

Respiren, tomen agüita

— flkt

de las cosas mas difíciles e interesantes para mi siempre han sido los elementos de HTML de formulario, desde hacer que se vean del mismo modo en todos los navegadores, luchar contra instalar un plugin que hace magia en sus node_modules para ponerle mil elementos encima que se ven hermosos, o jugar para ver hasta donde puede llegar un elemento que cada que sacan nuevo es ´ineditable´

el <input type=”color”> es un elemento que se ve re diferente en todos los navegadores (ni hablar de su menú contextual ! )

como se medio aprecia en la imagen (salió re chiquita) es un bloque de color dentro de algún contenedor con color de fondo y borde, que ni en su casa han de saber como quisieron alinear

homogeneizando el input”

en CSS es empezar de general a particular, así que comenzando por normalizar el elemento, hay que alinearlo, quitarle el padding, el borde y el color de fondo al contenedor

$height: 40px; 
$radius: 2px;

[type="color"] {
  display: inline-flex;
  vertical-align: bottom;
  border: none;
  border-radius: $radius;
  padding: 0; // para quitar el pading en FF
  height: $height;
  width: 100%;
  cursor: pointer;
}

para quitar el padding en chrome y safari se necesita editar el sub elemento ::-webkit-color-swatch-wrapper

::-webkit-color-swatch-wrapper {
  padding: 0;
}

por ultimo, para editar el bloque de color, necesitamos editar los sub elementos ::-webkit-color-swatch y ::-moz-color-swatch para quitarles los border y redondearlo como necesitemos

::-webkit-color-swatch {
  border: 0;
  border-radius: $radius;
}

::-moz-color-swatch {
  border: 0;
  border-radius: $radius;
}

listo! ya se ve igual en todos los navegadores (que estaba probando al menos)

ahora vamo a ponerlo buapo”

para hacerlo en tarjetas tipo ‘pantone’ primero hay que agregarle un elemento mas que pueda contener al input y output

para quienes no lo hayan utilizado, el <output> es un elemento de html muy bonito de los formularios, al que se le puede conectar su contenido con alguna formula definida en el formulario o en un input

con el atributo oninput=”colorhex.value=value” se liga el valor del input color con el valor del output que tenga el id colorhex

<input type="color" value="#6600ff" oninput="colorhex.value=value">
<output id="colorhex">#6600ff</output>

de esta manera cada que se seleccione un color diferente en el input, veremos el valor hexadecimal en el output (pa’ poder hacer más rápido el copy&paste)

para crear las tarjetas, agregamos un contenedor para tener en columnas los elementos <input> y <output> y editamos un poco los atributos de ambos para darle el estilo final

$radius: 10px;
$height: 220px;

.pantone-card {
  background: #fff;
  display: grid;
  width: $height * 1.25;
  border-radius: $radius;
  box-shadow: 0 2px 4px #0001;
  border: 4px solid #fff;
}

como cambiamos la variable height, el input de color quedará del nuevo valor de alto y se ajustará al ancho que tome la tarjeta… únicamente nos resta acomodarle el border-radius de los sub elementos ::-webkit-color-swatch y ::-moz-color-swatch para que el bloque de color quede redondeado de arriba y abajo quede recto

[type="color"] {
  display: inline-flex; // esto ya no aplica 
  vertical-align: bottom; // esto tampoco 
  border: none;
  border-radius: $radius;
  padding: 0;
  height: $height;
  width: 100%;
  cursor: pointer;
  
  &::-webkit-color-swatch-wrapper {
    padding: 0;
  }
  
  &::-webkit-color-swatch {
    border: 0;
    border-radius: $radius $radius 0 0; // arriba redondeado y abajo recto
  }
  
  &::-moz-color-swatch {
    border: 0;
    border-radius: $radius $radius 0 0; // arriba redondeado y abajo recto
  }
}

al final nada mas nos resta agregarle los estilos al <output> para que parezca el texto típico de las tarjetas de pantone

output {
  display: block;
  background: #fff;
  font-size: 28px;
  padding: 16px;
  line-height: 1em;
  font-family: 'helvetica', sans-serif;
  
  &:before {
    content: 'HEXADECIMAL';
    font-size: 14px;
    font-weight: bold;
    display: block;
  }
}

de referencia, acá dejo el ejemplo corriendo https://codepen.io/flkt-crnpio/pen/dygbBxy

Protocolo para la recolección de metadatos

Open Archive Initiative (OAI). La Iniciativa de Archivos Abiertos desarrolla y promueve los protocolos de interoperabilidad entre sistemas para facilitar el intercambio de archivos, en donde por archivo se debe entender, un repositorio de información almacenada.

Protocol for Metadata Harvesting (OAI — PMH). El protocolo para la recolección de metadatos define el mecanismo de interoperabilidad de repositorios para el intercambio de metadatos. Los proveedores de datos son repositorios que exponen metadatos estructurados a través de OAI-PMH, para que los proveedores de servicios realicen solicitudes para recopilar esos metadatos.

Características del protocolo OAI — PMH

Las solicitudes OAI-PMH se expresan como solicitudes de HTTP.

Las solicitudes OAI-PMH deben utilizar únicamente los métodos GET o POST y por consecuencia, los repositorios a los que se hagan dichas solicitudes deben soportar ambos tipos de métodos.

El método GET envía los parámetros por la URL. Los caracteres especiales que se utilicen en las URIs deben estar codificados como se muestra en la lista de reglas de sintaxis en la documentación de OAI

e.g.http://an.oa.org/OAI-script?verb=GetRecord&identifier=oai%3AarXiv.org%3Ahep-th%2F9901001&metadataPrefix=oai_dc

Para el método POST los argumentos son pasados en el cuerpo del mensaje. El Content-Type debe ser declarado como/x-www-form-urlencoded

e.g. POST http://an.oa.org/OAI-script HTTP/1.0
Content-Length: 82
Content-Type: application/x-www-form-urlencoded
verb=GetRecord&identifier=oai%3AarXiv.org%3Ahep-th%2F9901001&metadataPrefix=oai_dc

Tipos de consultas

OAI — PMH tiene un conjunto de seis verbos o servicios HTTP

• Identify . Mediante este servicio se obtiene la información acerca del repositorio de consulta. No se requiere ningún parámetro para hacer esta llamada.
• ListMetadataFormats . Usado para obtener la lista de formatos de metadata disponibles del repositorio de consulta. Opcionalmente se puede enviar el parámetro identifier para obtener los formatos para un récord.
• ListSets. Se utiliza para obtener la estructura de sets de un repositorio. Puede enviar el argumento resumptionToken si se cuenta con un token que regresa una llamada previa al servicio.
• ListIdentifiers . Para obtener las cabeceras de un récord específico. El único argumento requerido es el metadataPrefix, opcionalmente se pueden seleccionar las fechas mediante los argumentos from y until, también se puede enviar el argumento set para especificar el criterio de conjunto y el argumento resumptionToken si se cuenta con un token que regresa una llamada previa al servicio.
• ListRecords . Para obtener los récords de un repositorio. El único argumento requerido es el metadataPrefix, opcionalmente se pueden seleccionar las fechas mediante los argumentos from y until, también se puede enviar el argumento set para especificar el criterio de conjunto y el argumento resumptionToken si se cuenta con un token que regresa una llamada previa al servicio.
• GetRecord . Utilizado para obtener la metadata de un récord individual, existente en el repositorio de consulta. Para ejecutar esta llamada se requieren el identifier y el metadataPrefix de dicho elemento.

HTTP status code y códigos de error para las respuestas

La respuesta a las solicitudes OAI — PMH deben tener el formato de respuestas de HTTP, con los campos HTTP de encabezado adecuados y el Content-Type debe ser definido como text/xml .

El estatus de las respuestas se debe implementar con los códigos de estatus estándares HTTP status code que regresen información relevante de los repositorios.

Por ejemplo:
200 — Ok
302 — Para redireccionar temporalmente el repositorio (el URI temporal debe enviarse mediante un campo llamado Location en la respuesta del HTTP
503 — Fuera de servicio (con un campo Retry-After para especificar el tiempo especificado para volver a intentar)

Para los errores además de utilizar los códigos de estatus de HTTP, se complementan con otros elementos que de deben agregar en la respuesta. Cada mensaje de error debe tener un atributo code que especifique el OAI — PMH error y puede contener un atributo de texto para enviar información legible para un humano acerca del error.

El atributo code en el error debe seguir las siguientes reglas:

• Error code: badArgument Se utiliza para todos los servicios cuando la petición tiene atributos repetidos, le faltan parámetros o tienen una sintaxis ilegal.
• Error code: badResumptionToken Para los servicios ListIdentifiers, ListRecords, ListSets. Se envía cuando el valor del token no es válido o ha expirado.
• Error code: badVerb Se utiliza para informar que el verbo (o nombre de servicio) utilizado no existe en OAI-PMH o el campo está duplicado en la petición.
• Error code: cannotDisseminateFormat Para los servicios GetRecord, ListIdentifiers, ListRecords. Se envía cuando el formato de los metadatos identificado por el campo metadataPrefix, no es compatible con el elemento ni el repositorio.
• Error code: idDoesNotExis Se utiliza para los servicios GetRecord, ListMetadataFormats. Cuando el valor del identifier es desconocido o ilegal en el repositorio.
• Error code: noRecordsMatch Para los servicios ListIdentifiers, ListRecords. Se utiliza para decir que la combinación de la petición con los campos from, until, set y metadataPrefix devuelven una lista vacía.
• Error code: noMetadataFormats En el servicio ListMetadataFormats, se utiliza para informar que no existen formatos de metadata para el elemento solicitado.
• Error code: noSetHierarchy En las llamadas con el verbo ListSets, ListIdentifiers, ListRecords se utiliza para informar que el repositorio no soporta sets.

Archivo de respuesta

Todas las respuestas de OAI — PMH deben ser documentos en XML con el siguiente formato:

1. La primer etiqueta con la versión del xml en 1.0 con codificación utf8
2. El resto del documento debe estar contenido en la etiqueta OAI-PMH la cual debe tener los atributos xmlns , xmlns:xsi y xsi:schemaLocation
3. El primer elemento dentro de la etiqueta OAI-PMH debe ser responseDate con la fecha y la hora que es enviada la respuesta en UTC
4. El segundo elemento debe ser request con la url de la consulta y los atributos correspondientes al tipo de servicio solicitado.
5. El tercer elemento dependiendo de la consulta y la respuesta, puede ser o el mensaje de error o el elemento que retorne la consulta.

E.j.

<?xml version="1.0" encoding="UTF-8" ?>
<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/
         http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
 <responseDate>2002-05-01T19:20:30Z</responseDate>
 <request verb="GetRecord" identifier="oai:arXiv.org:hep-th/9901001"
          metadataPrefix="oai_dc">http://an.oa.org/OAI-script</request> 
 <GetRecord>
  <record>
      ...
  </record>
 </GetRecord> 
</OAI-PMH>

Respuestas y su control de flujo

Para las llamadas que devuelven listas la respuesta puede contener un fragmento de la lista junto con un resumptionToken, el cual sirve para hacer una llamada al mismo servicio y obtener el siguiente fragmento de información.

Los atributos opcionales como parte del resumptionToken son el expirationDate, un UTCdatetime que especifique la fecha de expiración del token, y el atributo completeListSize con el tamaño de la lista completa.

Los repositorios que implementan tokens de reanudación deben hacerlo de una manera que permita a los recolectores reanudar una secuencia de solicitudes de listas incompletas volviendo a emitir una solicitud de lista con el token de reanudación más reciente.

Referencias

• Open Archives Initiative - Protocol for Metadata Harvesting - v.2.0
• OAI para principiantes - OA-Forum tutorial

Así que me leí un montón de opciones que otra gente había usado y terminé con un bonito pipe, un servicio y un archivo con los arreglos de la traducción.

El archivo de la traducción es muy simple, es un arreglo las palabras que necesites cambiar dentro de un arreglo de los lenguajes que quieras mostrar. Yo lo guarde dentro de un archivo al que nombre de menu-translation.ts , lo dejo por futuras referencias, ya que después obviamente se necesita cargar en el servicio.

export const MENU = {
  en: {
    home: 'Home',
    projects: 'Projects',
    studio: 'Studio',
    full: 'Full Project'
  },
  es: {
    home: 'Inicio',
    projects: 'Proyectos',
    studio: 'Estudio',
    full: 'Ver Proyecto'
  }
};

En el servicio translate.service se carga el menú de traducción y con un un simple if*(porque pues nada mas tengo dos lenguajes, no vale la pena hacerle más) cargas el lenguaje seleccionado, para que cuando entre a la vista, el pipe regrese, del idioma seleccionado la palabra del menu correspondiente. También el servicio debe incluir otra función que guarde el lenguaje seleccionado, para luego agregárselo al botón de cambio de idioma en la vista.

import { Injectable } from ‘@angular/core’;
import { Observable } from ‘rxjs/Observable’;

import { MENU } from ‘./menu-translation’;

@Injectable()
export class TranslateService {
 private _currentLang: string;

constructor() { }

getCurrentLang(): string {
 if (!this._currentLang) {
  this._currentLang = ‘es’;
 }
 return this._currentLang;
}

setCurrentLang(lang: string) {
 this._currentLang = lang;
}

getMenuTranslation(menuName: string): Observable<string> {
 this.getCurrentLang();
 return MENU[this._currentLang][menuName];
 }
}

El pipe debe cargar el servicio de traducción, para utilizar sus funciones, y debe tener la propiedad pure:none . Esto no es muy recomendado porque lo que hace es que todo el tiempo esta observando por cambios, si utilizas mucho esta propiedad, puedes matar tu aplicación de lo lenta que va a ser. Pero otra vez, como lo que necesitaba es muy simple pues vale, el tiempo de espera no es nada, no se percibe.

import { Pipe, PipeTransform } from ‘@angular/core’;
import { Observable } from ‘rxjs/Observable’;
import { TranslateService } from ‘./translate.service’;

@Pipe({
 name: ‘translate’,
 pure: false
})
export class TranslatePipe implements PipeTransform {

constructor(private translateService: TranslateService) { }

transform(text: string): Observable<string> {
 return this.translateService.getMenuTranslation(text);
 }

}

Aquí mezclo la vista y el controlador, la primer línea tiene la función del controlador que manda llamar la función del servicio para setear el lenguaje al que le den click en la vista. Los botones, ya en la vista, simplemente mandan llamar ésta función cuando se les da click. Lo que genera el cambio de traducción en el texto del menú, en donde el primer término dentro de las llaves es el nombre específico del elemento del menú a traducir y el segundo término es el nombre del pipe.

changeLang(languaje: string) {
  this.translateService.setCurrentLang(languaje);
}

<button type=”button” (click)=”changeLang(‘es’)”>esp</button> 
<button type=”button” (click)=”changeLang(‘en’)”>eng</button>

<nav>
  <a routerLink="/home">{{ 'home' | translate }}</a>
  <a routerLink="/projects">{{ 'projects' | translate }}</a>
  <a routerLink="/studio">{{ 'studio' | translate }}</a>
</nav>

Y listo, super simple, fácil de usar, rápido de hacer. Espero que le sirva a alguien más, aunque en realidad también lo guardo para no olvidar como repetirlo :}

Saludos a todos, besitos locos.

Ah! y si alguien quiere leer algunos de los links que leí para hacer ésto, los dejo acá.

• Simple Language Translation in Angular 2 (Part 1)
• Handling Observables with NgIf and the Async Pipe

chau

Una calurosa mañana de mayo, caminábamos con Esparragus elelelperrito hablando del capítulo de Bill Nye Saves the World que había visto el día anterior. Trataba de la comida del futuro, camarones hechos con algas, ensaladas con insectos y un emparedado de carne creada a partir de células animales.

Acerca de las algas me imaginé que podrían saber bien, con los insectos meh! al menos aquí en México ya se comen, así que pues me pareció hasta falta de imaginación, pero carne creada? carne?! generada!! cómo!?

Dimos vuelta en la estatua del changuito a fuera del bar de la esquina y la conversación giró hacia otro lugar, ahora estábamos hablando de las cosas sagradas y de porqué el imaginarme comiendo carne creada me ocasionaba tanto conflicto.

Jonás me contaba de un análisis de Jonathan Haidt de los tipos de personas y su toma de desiciones y de cómo por muy liberales que sean al momento de llegar a las cosas ‘sagradas’ todos se vuelven tan conservadores.

— Piensa en los bebés. -me dijo- Cada que se toca un tema con los niños todos son super cuidadosos, conservadores.

— Y claro! es un tema de la supervivencia de la especie, es algo biológico, casi que podría decir que lo traemos escrito en las células. -dije

— Si! -respondió- Entonces porqué no pensando en eso y debido a la cantidad de gente que somos, con la premisa de que los bebes son sagrados, no podemos abordar el tema de la comida y pensar en solucionarlo, en lugar de extrañarnos con la creación celular en laboratorio de la misma.

— Pues porque la comida es más sagrada! -respondí

— El problema es la cantidad de gente! -continué

… me quedé callada de repente y pensé

Oh no! Soy Thanos!

Porque no puede venir mejor Tuf y salvarnos a todos.

La idea de #caminandoConEsparragus es platicar encuentros chistosos de ideas que pasan esas mañanas en que uno sale de paseo recién despertando con la primer taza de café. No se lo tomen muy en serio.

Referencias:

• Bill Nye . Quién no conoce a Bill Nye! Bueno, es un ingeniero mecánico que se dedica a la difusión de la ciencia.
• Jonathan Haidt . Psicólogo social norteamericano.
• Thanos . En la última película de Avengers: Infinity War. Ni les cuento que pasa porque me matan si no la han visto.
• Tuf . De Los viajes de Tuf, un libro de George R. R. Martin. Léanlo! en serio esta muy bueno.

La primera vez que quise hacer una librería de CSS, fue cuando leí de que el problema de que todo se parezca en la web, es porque todo el mundo utiliza la misma librería (en el mejor de los casos) o los mismos templates.

Por el 2016 era aburrido pasar el día navegando y ver como con las horas vas confirmando esa teoría, bootstrap por aquí bootstrap por allá, ese maldito botón azul por todos lados, así que decidí hacer algo al respecto, mi primer librería, única, especial, la mejor, capaz de romper con todo!

Pero lo único que rompí fue mi cabeza (y luego unas cuantas páginas en las que la probé).

Comencé queriendo cambiar todo, desde el origen, incluso el código parecía espagueti ¿Porqué he de seguir las reglas, si justamente ese es el problema?

Ingenua, ¿no?

Me di cuenta que la librería es un modelo que uno propone al mundo y que mientras menos edición necesites hacer para usarla, ahorras tiempo y trabajo, lo que la hace útil. Y lo que quería que sobre todo mi librería fuera útil.

Cuando el proyecto creció comencé a estandarizarlo, para poder leerlo al menos, porque mantener un código espagueti es un dolor de cabeza, incluso en el pastafarismo.

Conforme tomaba una mejor forma de algo utilizable, más se parecía al resto de los frameworks. Al intentar estandarizar algo con tantas variantes (que sea funcional para tiendas, artistas, galerías, blogs, canales) terminó perdiendo su particularidad. Ese estilo único que quería lograr, parecía ser solo lograble al hacerlo de manera artesanal, creando una hoja de estilos única desde el interlineado hasta los elementos embebidos.

Terminé de editar la librería peleando un poco entre la estandarización y la particularidad. En ella puedes editar algunas variables generales para cambiar características básicas, como el color, la fuente o el espacio entre los elementos, pero en lugar de librería creo que se asemeja más a un diccionario de estilos.

No pude estandarizarla sin perder el estilo, debía de ser una herramienta para optimizar el tiempo eliminando el código repetitivo, tanto dentro del proyecto como entre un proyecto y otro. Además, para funcionar en varios tipos de proyectos debía ser capaz de funcionar desarticuladamente, sin cargar archivos que jamas se usan. Debía mantenerse encapsulada, por si tiene que coexistir con otras librerías, no se deformaran una con la otra. Debía ser fácilmente manipulable para acercarme lo mas posible al resultado final que es la guía de estilo del proyecto a desarrollar. Y… debía cambiar tanto el proyecto que mejor convenía volver a comenzar.

Reconociendo la derrota.

Un poco decepcionada le di carpetazo al proyecto. Pitaya murió unos meses después de su creación, pero decidí no borrarla porque me podría servir de base de futuras referencias.

Le aprendí bastante mientras estuve peleando con ella, lo mas memorable fueron un par de experimentos con el input checkbox y su atributo checked, para crear pestañas y las secciones colapsables, que ya existen nativamente con la etiqueta de<details>, aunque en aquel momento no la conocía.

Aquí dejo las ligas de Pitaya, por si alguien está de curioso.

• http://flkt-crnpio.github.io/pitaya/
• https://codepen.io/flkt-crnpio/pen/WxROwy
• https://codepen.io/flkt-crnpio/pen/gMgbvN
• https://github.com/flkt-crnpio/pitaya

Tomar aliento y volverlo a intentar.

Al final he comenzado una nueva librería modular, de hecho cada modulo es un proyecto separado de github y se pueden utilizar independientes.

He comenzado como debí comenzar, desde el normalize y aunque son proyectos independientes, están estructurados de la misma manera para no volverme a perder.

Además, esta vez pude implementar pruebas reales en sitios con diferentes requerimientos.

Aun sigo desarrollando módulos para este nuevo proyecto, siento que la base esta terminada, pero sigo sin documentar asi que ya hablaré de éste tema después, cuando pueda poner ejemplos.

Gracias por leer!