Replace uses of the 'alt' attribute with <img> tags with 'title' instead.

_docs/concepts/network-and-auth/auth.md

@@ -32,7 +32,7 @@ In future versions it will also provide:
 
 The figure below shows the Istio Auth architecture, which includes three components: identity, key management, and communication security. It describes how Istio Auth is used to secure service-to-service communication between service A, running as service account "foo", and service B, running as service account "bar".
 
-<img style="display:block;margin:auto" src="./img/auth/auth.svg" alt="Istio Auth Architecture." />
+<img style="display:block;margin:auto" src="./img/auth/auth.svg" title="Istio Auth Architecture." />
 
 ## Components
 

_docs/concepts/policy-and-control/mixer.md

@@ -25,7 +25,7 @@ management. Services that leverage Mixer in this way are abstracted from environ
 easing the process of hosting the code in different environments (different clouds and on-prem). (Please note that 
 as of the Alpha release of Istio, only Envoy can call Mixer directly.)
 
-<img style="display:block;width:60%;margin:auto;" src="./img/mixer/traffic.svg" alt="Flow of traffic." />
+<img style="display:block;width:60%;margin:auto;" src="./img/mixer/traffic.svg" title="Flow of traffic." />
 <p style="text-align:center;">Mixer Traffic Flow</p>
 
 Mixer provides three core features:
@@ -57,7 +57,7 @@ checking, and more. Adapters enable Mixer to expose a single consistent API, ind
 The exact set of adapters used at runtime is determined through configuration and can easily be extended
 to target new or custom infrastructure backends.
 
-<img style="width:35%;display:block;margin:auto;" src="./img/mixer/adapters.svg" alt="Mixer and its adapters." />
+<img style="width:35%;display:block;margin:auto;" src="./img/mixer/adapters.svg" title="Mixer and its adapters." />
 
 ## Configuration state
 
@@ -101,7 +101,7 @@ configured through a simple declarative form as described [here](./mixer-config.
 Processing phase creates a set of adapter parameters. The Adapter Dispatching phase invokes the adapters
 associated with each aspect and passes them those parameters.
 
-<img style="display:block;width:50%;margin:auto;" src="./img/mixer/phases.svg" alt="Phases of mixer request processing" />
+<img style="display:block;width:50%;margin:auto;" src="./img/mixer/phases.svg" title="Phases of mixer request processing" />
 <p style="text-align:center;">Request Phases</p>
 
 ## Scripting

_docs/concepts/traffic-management/load-balancing.md

@@ -21,7 +21,7 @@ registry and provides a platform-agnostic service discovery
 interface. Envoy instances in the mesh perform service discovery and 
 dynamically update their load balancing pools accordingly.
 
-<img class="center-image-75" src="./img/manager/LoadBalancing.svg" alt="Istio - Discovery & Load Balancing." />
+<img class="center-image-75" src="./img/manager/LoadBalancing.svg" title="Istio - Discovery & Load Balancing." />
 
 As illustrated in the figure above, services in the mesh access each other
 using their DNS names. All HTTP traffic bound to a service is automatically

_docs/concepts/traffic-management/manager.md

@@ -15,7 +15,7 @@ APIs for [service discovery](https://lyft.github.io/envoy/docs/configuration/clu
 platform-specific nuances, simplifying the design and increasing
 portability across platforms.
 
-<img class="center-image-75" src="./img/manager/ManagerAdapters.svg" alt="Istio-Manager - architecture." />
+<img class="center-image-75" src="./img/manager/ManagerAdapters.svg" title="Istio-Manager - architecture." />
 
 As illustrated in the figure above, Istio-Manager maintains a canonical representation of services in the
 mesh that is independent of the underlying platform. Platform-specific

_docs/concepts/traffic-management/overview.md

@@ -14,7 +14,7 @@ set of pods/VMs should receive traffic (e.g., by adding/removing specific
 labels). Unlike existing techniques, Istio decouples traffic flow and infrastructure
 scaling. 
 
-<img src="./img/manager/TrafficManagementOverview.svg" alt="Traffic Management with Istio." />
+<img src="./img/manager/TrafficManagementOverview.svg" title="Traffic Management with Istio." />
 
 As illustrated in the figure above, Istio allows operators to control what
 percentage of traffic should be routed to these pods or which requests

_docs/concepts/traffic-management/request-routing.md

@@ -27,7 +27,7 @@ additional control over traffic between services.
 
 ## Communication between services
 
-<img class="center-image-75" src="img/manager/ServiceModel_Versions.svg" alt="Istio service model - service versions." />
+<img class="center-image-75" src="img/manager/ServiceModel_Versions.svg" title="Istio service model - service versions." />
 
 As illustrated in the figure above, clients of a service have no knowledge
 of different versions of the service. They can continue to access the
@@ -58,4 +58,4 @@ operators can add failure recovery features such as circuit breakers,
 impose rate limits via Mixer, and provide authentication using
 Istio-Auth service.
 
-<img src="img/manager/ServiceModel_RequestFlow.svg" alt="Istio service model - ingress and egress Envoy." />
+<img src="img/manager/ServiceModel_RequestFlow.svg" title="Istio service model - ingress and egress Envoy." />

_docs/concepts/what-is-istio/architecture.md

@@ -11,7 +11,7 @@ type: markdown
 
 This page presents an architectural overview for the Istio service mesh.
 
-<img src="./img/architecture/arch.svg" alt="The overall architecture of an Istio-based application." />
+<img src="./img/architecture/arch.svg" title="The overall architecture of an Istio-based application." />
 
 ## The sidecar model